both ignore the return value. For that matter, filemap_fdatasync
itself has no return value. This seems to indicate that various
internal errors during fsync() will not result in an error to the
application. Looking at some of the possible call graphs, such
errors might occur in any of the write_full_page implementations,
including calls to:
get_block() (e.g., block_write_full_page, block_prepare_write)
various EIO conditions, mostly sanity checks
(e.g., block_prepare_write, nfs_writepage, reiserfs, smbfs)
calls to file_operations write() method though
ENOMEM condition (e.g., shmem_writepage)
My guess is that the file system's get_block() method usually
cannot be called from within the block_write_full_page method
during writepage, which is called directly by most file systems,
because the full page would have all its buffers mapped prior to
writepage(). Is this true?
However, NFS, ReiserFS, SMBFS, and shmem do not simply call
block_write_full_page() and each performs error checking in this code
path. It looks as if these errors will not reach the application
to which they belong when writepage() is called via fsync(). This
is definetly the case for ReiserFS, but I do not understand the
other systems well enough to evaluate their writepage() code path.
It looks less significant that shrink_cache() does not use the
return value, but if writepage() truly should have its return value
ignored then the declaration should not have it returning an int.
That would at least notify the file system authors that returning
an error condition does no good.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/