Pavel,
Jeff and I talked about invalidate_mapping and its uses this
afternoon. A few comments:
1) Take a look at what happens on filemap_fdatawait call in
invalidate_mapping to see if it makes sense to return errors through
back to some of the callers of invalidate_mapping, in particular,
strict_fsync. If we can't write out the file data (ENOSPC, or host
down etc.), we want to make sure that the return code gets sent back
on any calls that can reasonably expect such an error.
2) If invalidate_inode_pages2 fails (e.g. with EBUSY, because one of
the pages couldn't be freed from the mapping because it just got
redirtied right after we flushed it the line before) we set the
mapping to invalid but don't check
cifs_i->invalid_mapping
in many places. Should we add checks for cifs_i->invalid_mapping in
more places?
3) The error message below in invalidate_mapping (on EBUSY) should
be removed or changed to an cFYI:
cERROR(1, "%s: could not invalidate inode %p", __func__, inode);
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
