Nick Piggin wrote:
On Wed, Oct 29, 2008 at 10:56:36AM -0400, Chris Mason wrote:
On Wed, 2008-10-29 at 09:32 -0400, Ric Wheeler wrote:
Jamie Lokier wrote:
Is there anything that particularly makes it a file operation
as opposed to an inode operation?
In principle, is fsync() required to flush all dirty data written
through any file descriptor ever, or just dirty data written through
the file descriptor used for fsync()?
-- Jamie
--
http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html
Is a pointer to what seems to be the official posix spec for this - it
is definitely per file descriptor, not per file system, etc...
Maybe I'm reading Jamie's question wrong, but I think he's saying:
/* open exactly the same file twice */
fd = open("file");
fd2 = open("file");
write(fd, "stuff")
write(fd2, "more stuff")
fsync(fd);
Does the fsync promise "more stuff" will be on disk? I think the answer
should be yes.
I think so. And this is in the context of making ->fsync an inode
operation and avoid the NFS NULL-file problem... I don't think there
is any fd specific metadata that fsync has to deal with? Any other
reasons it has to be a file operation?
NO, or at least *not the posix definition*. It is normal
in unix-like operating systems to always flush everything
dirty on the inode no matter what stream it arrived on.
Flushing everything is permitted but not the requirement so
applications must not expect this is *promised* or they
will not be portable. It is only guaranteed that "stuff"
in this example will be on disk.
AFAIK the fsync semantic comes from the days of dinosaurs,
mainframes, and minicomputers... when a lot of operating
systems had user-space libraries that buffered the I/O.
On fsync(fd), the "fd2" data would still be in user-space.
jim
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
