fsync() transfers ("flushes") all modified in-core data of (i.e.,
modified buffer cache pages for) the file referred to by the file
descriptor fd to the disk device (or other permanent storage device)
where that file resides. The call blocks until the device reports
that the transfer has completed. It also flushes metadata information
associated with the file (see stat(2)).
Calling fsync() does not necessarily ensure that the entry in the
directory containing the file has also reached disk. For that an
explicit fsync() on a file descriptor for the directory is also
needed.
...
RETURN VALUE top
On success, these system calls return zero. On error, -1 is
returned, and errno is set appropriately.
--------------
I guess it should mention that any errors during fsync are only
mentioned to the first process calling it... which means that if you
write file
fsync file
fsync .
... and someone else does "fsync ." in the meantime, you may get
success when in fact directory entry of file is not written to the
disk.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel,
On Tue, Dec 2, 2008 at 7:06 AM, Pavel Machek <[email protected]> wrote:
>
> fsync() transfers ("flushes") all modified in-core data of (i.e.,
> modified buffer cache pages for) the file referred to by the file
> descriptor fd to the disk device (or other permanent storage device)
> where that file resides. The call blocks until the device reports
> that the transfer has completed. It also flushes metadata information
> associated with the file (see stat(2)).
>
> Calling fsync() does not necessarily ensure that the entry in the
> directory containing the file has also reached disk. For that an
> explicit fsync() on a file descriptor for the directory is also
> needed.
>
> ...
> RETURN VALUE top
>
> On success, these system calls return zero. On error, -1 is
> returned, and errno is set appropriately.
>
>
> --------------
>
>
> I guess it should mention that any errors during fsync are only
> mentioned to the first process calling it... which means that if you
>
> write file
> fsync file
> fsync .
>
> ... and someone else does "fsync ." in the meantime, you may get
> success when in fact directory entry of file is not written to the
> disk.
Could you provide some pointers to supporting information / mail
threads, relating to this?
Also, I'm still not 100% clear what you are saying above. Do you mean
that in this scenario, an error may occur but the first caller above
won't know of it? (It would help if you could write a few sentences
that you think should be in the man page.)
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
> Pavel,
> Could you provide some pointers to supporting information / mail
> threads, relating to this?
Mail thread on lkml, "writing to disk, not...."
> > write file
> > fsync file
> > fsync .
> >
> > ... and someone else does "fsync ." in the meantime, you may get
> > success when in fact directory entry of file is not written to the
> > disk.
> Also, I'm still not 100% clear what you are saying above. Do you mean
> that in this scenario, an error may occur but the first caller above
> won't know of it?
Yes.
> (It would help if you could write a few sentences
> that you think should be in the man page.)
Ok, see below.
> > fsync() transfers ("flushes") all modified in-core data of (i.e.,
> > modified buffer cache pages for) the file referred to by the file
> > descriptor fd to the disk device (or other permanent storage device)
> > where that file resides. The call blocks until the device reports
> > that the transfer has completed. It also flushes metadata information
> > associated with the file (see stat(2)).
> >
> > Calling fsync() does not necessarily ensure that the entry in the
> > directory containing the file has also reached disk. For that an
> > explicit fsync() on a file descriptor for the directory is also
> > needed.
Replace paragraph with:
On newly created files, explicitely calling fsync on a file descriptor
for a directory is also needed, because calling fsync() on file does
not necessarily ensure that the entry in the directory containing the
file has reached disk.
> >
> > ...
> > RETURN VALUE top
> >
> > On success, these system calls return zero. On error, -1 is
> > returned, and errno is set appropriately.
I'd add:
After I/O error, fsync() only returns error condition to the first
process that finishes fsync(). Therefore special care must be taken to
coordinate different processes trying to write data to file/directory.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html