>Please quote chapter and verse --- my reading of SUS shows no such
>requirement.
>
>fsync is required to force "all currently queued I/O operations
>associated with the file indicated by file descriptor fildes to the
>synchronised I/O completion state." But as you should know, directory
>entries and files are NOT the same thing in Unix/SUS.
But does fsync() have any meaning if it doesn't ensure the file is
visible within the filesystem?
This all comes back to the fact that old UFS's made directory
operations syncronous, at a substantial cost in performance. Writing
the directory data wasn't necessary for them, because it was already
commited when the creat() call returned.
I can easily understand people's asthetic objection to having fsync
touch the directory object as well as the file, however what meaning
does fsync() have it it doesn't - under linux, it tells usermode "yes,
your object is committed, but it might be in lost+found next time you
want it", and with the syncronous UFS implementations, it tells
usermode "yes, your object is committed, you can find it where you left
it (unless the directory was corrupted)".
---
Andrew McNamara (System Architect)
connect.com.au Pty Ltd
Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia
Phone: +61 2 9409 2117, Fax: +61 2 9409 2111
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:14 EST