fsync - Linux

This is a discussion on fsync - Linux ; Hi, The fsync() function is not flushing data to the disk in my program. Why not? The file is opened read/write and non-blocking. It is memory mapped with mmap (), and accessed by several forked processes through the memory map ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: fsync

  1. fsync

    Hi,

    The fsync() function is not flushing data to the disk in my program.
    Why not?

    The file is opened read/write and non-blocking. It is memory mapped
    with mmap (),
    and accessed by several forked processes through the memory map only
    (no read/write
    calls).

    This is a problem in the rare event of a system crash.

    Thanks,
    -Mike




  2. Re: fsync

    Mike writes:
    > The fsync() function is not flushing data to the disk in my program.
    > Why not?
    >
    > The file is opened read/write and non-blocking. It is memory mapped
    > with mmap (),


    Ehh ... have you tried 'msync'?

  3. Re: fsync

    On Mon, 24 Dec 2007 20:59:33 -0800 (PST) Mike wrote:

    | The fsync() function is not flushing data to the disk in my program.
    | Why not?
    |
    | The file is opened read/write and non-blocking. It is memory mapped
    | with mmap (),
    | and accessed by several forked processes through the memory map only
    | (no read/write
    | calls).

    The fsync() call only flushes I/O associated with a file descriptor.
    Once a file has been memory mapped, you can then close the descriptor.
    There is no association held between the descriptor and the memory that
    has been mapped, besides the coincidence of involving the same data
    blocks on disk. Use msync() to update the data contents then sync() to
    be sure all the metadata is updated.


    | This is a problem in the rare event of a system crash.

    Or power failure.

    Or accidental press of reset. I did that once while removing my coat.
    While swinging around to pull the other arm out of the other sleeve, one
    side of the coat hit the reset button. I now take my coat off at more
    distance from computers, even though the chance of that is so low.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-12-26-0736@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: fsync

    On Dec 26, 1:44 pm, phil-news-nos...@ipal.net wrote:
    > On Mon, 24 Dec 2007 20:59:33 -0800 (PST) Mike wrote:
    >
    > | The fsync() function is not flushing data to the disk in my program.
    > | Why not?


    >
    > Use msync() to update the data


    Ok, thanks guys.

    Also,
    I have not concerned myself with how mmap() works, so this is a
    surprise to me.
    I think it might be helpful to others if the man page for fsync()
    mentioned msync()
    in the description, and that fsync() does not work for mmap()'ed file
    access.
    What do you think?

    -Mike

  5. Re: fsync

    Mike writes:

    [...]

    > Also, I have not concerned myself with how mmap() works, so this is
    > a surprise to me. I think it might be helpful to others if the man
    > page for fsync() mentioned msync() in the description, and that
    > fsync() does not work for mmap()'ed file access.
    >
    > What do you think?


    The mmap(2) manpage documents the need for using msync in certain
    cases:

    MAP_SHARED Share this mapping with all other processes that
    map this object. Storing to the region is equivalent to
    writing to the file. The file may not actually be updated
    until msync(2) or munmap(2) are called.

    fsync(2) contains the following text:

    fsync() transfers ("flushes") all modified in-core data of
    [...] the file referred to by the file descriptor fd to the
    disk device [...] where that file resides.

    I think it is reasonable to expect people to read the mmap manpage
    before using this system call. Additionally, it is fairly self-evident
    that the kernel cannot know which areas of a memory-mapped file have
    been modified by means of memory writes if the corresponding
    memory is an ordinary part of the address space of some process, and
    consequently, it cannot sync the on fsync, either.

  6. Re: fsync

    Mike writes:

    [...]

    > Also, I have not concerned myself with how mmap() works, so this is
    > a surprise to me. I think it might be helpful to others if the man
    > page for fsync() mentioned msync() in the description, and that
    > fsync() does not work for mmap()'ed file access.
    >
    > What do you think?


    The mmap(2) manpage documents the need for using msync in certain
    cases:

    MAP_SHARED Share this mapping with all other processes that
    map this object. Storing to the region is equivalent to
    writing to the file. The file may not actually be updated
    until msync(2) or munmap(2) are called.

    I think it is reasonable to expect people to read the mmap manpage
    before using this system call.

  7. Re: fsync

    Mike wrote:
    > Hi,
    >
    > The fsync() function is not flushing data to the disk in my program.
    > Why not?
    >
    > The file is opened read/write and non-blocking. It is memory mapped
    > with mmap (),
    > and accessed by several forked processes through the memory map only
    > (no read/write
    > calls).
    >
    > This is a problem in the rare event of a system crash.


    Turn off disk controller write-back cache via hdparm, e.g.

    sudo hdparm -W 0 /dev/dsa3

    --
    Tor

  8. Re: fsync

    On Dec 27, 5:19 pm, Rainer Weikusat wrote:
    > Mike writes:
    >
    > [...]
    >
    > > Also, I have not concerned myself with how mmap() works, so this is
    > > a surprise to me. I think it might be helpful to others if the man
    > > page for fsync() mentioned msync() in the description, and that
    > > fsync() does not work for mmap()'ed file access.

    >
    > > What do you think?

    >
    > The mmap(2) manpage documents the need for using msync in certain
    > cases:
    >
    > MAP_SHARED Share this mapping with all other processes that
    > map this object. Storing to the region is equivalent to
    > writing to the file. The file may not actually be updated
    > until msync(2) or munmap(2) are called.
    >
    > I think it is reasonable to expect people to read the mmap manpage
    > before using this system call.


    This mode, MAP_SHARED, is indeed the mode my program uses.
    And I probably overlooked the mention of msync() when I read
    the man page for mmap().

    But, I ask, if "Storing to the region is _equivalent_ to writing to
    the file", then should I not expect fsync() on that file
    descriptor to work?

    -Mike

  9. Re: fsync

    On Dec 27, 9:18 am, Rainer Weikusat wrote:

    > fsync(2) contains the following text:
    >
    > fsync() transfers ("flushes") all modified in-core data of
    > [...] the file referred to by the file descriptor fd to the
    > disk device [...] where that file resides.


    Then 'fsync' is documented incorrectly. Data modified by 'mmap' of the
    file is modified in-core data. It is definitely the same file referred
    to by the file descriptor.

    Other documentation for 'fsync' also suggests that this happens. For
    example:

    fsync, fdatasync - synchronize a file's complete in-core
    state with
    that on disk

    The POSIX definition is similar. If it doesn't sync operations done
    through a memory map, it is broken. It must synchronize the *file*
    itself.

    DS

  10. Re: fsync

    David Schwartz writes:
    > On Dec 27, 9:18 am, Rainer Weikusat wrote:
    >
    >> fsync(2) contains the following text:
    >>
    >> fsync() transfers ("flushes") all modified in-core data of
    >> [...] the file referred to by the file descriptor fd to the
    >> disk device [...] where that file resides.

    >
    > Then 'fsync' is documented incorrectly. Data modified by 'mmap' of the
    > file is modified in-core data.


    That the man page refers to mmap'ed areas as well may be what you
    believe to be the case, but since mmap explicitly documents something
    different, this belief is wrong. Partially, this is a historic
    phenomenon, because the I/O operations on file descriptors predate the
    memory-mapping facility and used to refer to the 'buffer cache' in the
    kernel. Nowadays, Linux has a unified page cache, but reportedly, some
    Unices (ie HP-UX) haven't.

    > Other documentation for 'fsync' also suggests that this happens. For
    > example:
    >
    > fsync, fdatasync - synchronize a file's complete in-core
    > state with
    > that on disk
    >
    > The POSIX definition is similar.


    The fsync() function shall request that all data for the open
    file descriptor named by fildes is to be transferred to the
    storage device associated with the file described by
    fildes. The nature of the transfer is implementation-defined.

    It is reasonable that someone without knowledge of UNIX(*) evolution
    would assume that fsync applies to mmap'ed areas of a file, but it
    generally doesn't, except insofar this has been implemented in the
    kernel 'afterwards' (eg Linux documents that it doesn't, FreeBSD that
    it does, HP-UX that 'you are not supposed to ask this question,
    but you would be a fool counting on it' and Solaris basically 'just
    call msync and don't ask').

  11. Re: fsync

    On Dec 29 2007, 3:09 am, Rainer Weikusat
    wrote:

    > It is reasonable that someone without knowledge of UNIX(*) evolution
    > would assume that fsync applies to mmap'ed areas of a file, but it
    > generally doesn't, except insofar this has been implemented in the
    > kernel 'afterwards' (eg Linux documents that it doesn't, FreeBSD that
    > it does, HP-UX that 'you are not supposed to ask this question,
    > but you would be a fool counting on it' and Solaris basically 'just
    > call msync and don't ask').


    You say that "Linux documents that it doesn't", but my Linux
    documentation says that it does:

    fsync() copies all in-core parts of a file to disk, and waits
    until the
    device reports that all parts are on stable storage.

    DS

  12. Re: fsync

    David Schwartz writes:
    > On Dec 29 2007, 3:09 am, Rainer Weikusat
    > wrote:
    >
    >> It is reasonable that someone without knowledge of UNIX(*) evolution
    >> would assume that fsync applies to mmap'ed areas of a file, but it
    >> generally doesn't, except insofar this has been implemented in the
    >> kernel 'afterwards' (eg Linux documents that it doesn't, FreeBSD that
    >> it does, HP-UX that 'you are not supposed to ask this question,
    >> but you would be a fool counting on it' and Solaris basically 'just
    >> call msync and don't ask').

    >
    > You say that "Linux documents that it doesn't", but my Linux
    > documentation says that it does:


    | That the man page refers to mmap'ed areas as well may be what you
    | believe to be the case, but since mmap explicitly documents something
    | different, this belief is wrong.

    This hasn't changed since the last time I wrote it. If you think that
    this is an issue with the fsync-manpage, consider submitting a patch.

    Apart from this, the original claim is fiction on 'current' (2.6.23) Linux,
    anyway, since msync only calls fsync, anyway (it is not 'obsolete', as
    the FreeBSD man page states, because a process can retain mmap'ed
    areas after closing any descriptor refering to a particular file).


+ Reply to Thread