Messages in this thread |  | | Date | Fri, 19 Oct 2001 12:05:44 -0700 | From | Josh MacDonald <> | Subject | Why is writepage() return value not used? |
| |
Reading through 2.4.12 sources, I observe that the two calls to the address_space writepage() method, found in these functions:
filemap_fdatasync shrink_cache
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 nfs_writepage_sync
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.
-josh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |