Messages in this thread | | | Date | Tue, 9 Jul 2002 14:58:53 -0400 | From | "Bill Rugolsky Jr." <> | Subject | Re: [NFS] Re: [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories on NFS mounts |
| |
On Tue, Jul 09, 2002 at 01:22:29PM -0400, Richard B. Johnson wrote: > Really? Then what is the meaning of fsync() on a read-only file- > descriptor? You can't update the information you can't change.
Eh? I do an fchmod() on a readonly descriptor, then I call fsync() on that descriptor. The inode gets sync'd to disk (with updated mode and c_time). So no, I don't need a writable descriptor to call fsync(). The only question is *what* gets sync'd when I call fsync() on an O_RDONLY file-descriptor.
SUSv3 (http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html) says "The fsync() function forces all currently queued I/O operations associated with the file indicated by file descriptor fildes to the synchronised I/O completion state."
It appears from this wording that the file-descriptor is *merely* a handle referring to the inode, and that *all* outstanding I/O on the inode [within the "system"] is performed. In other words, if I had several different file handles referring to the same inode (but different kernel "struct file" objects), all inode data and meta-data updates prior to the fsync() call would be synchronized. It doesn't say that explicitly, but given the usual visibility rules regarding writes, etc., that is the "natural" interpretation. [Caveat: mmap()] To state it succinctly: if other (data or meta-data) writes are visible to the process doing the fsync(), they need to be sync'd too.
In the case of directories, there is no file handle "doing the writing" -- the kernel does that, so absent the ability to call fsync() on a readonly handle to a directory, i.e. fsync(dirfd(dir)), there is no convenient way to sync the directory contents. Calling fsync() on every file in a directory does not necessitate syncing the directory!
Regards,
Bill Rugolsky - 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/
| |