lkml.org 
[lkml]   [2002]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories on NFS mounts
    On Mon, 15 Jul 2002, Richard B. Johnson wrote:

    > These are things that should be addressed rather than flamed-
    > away. I think that the intent of fsync() on a file is to make
    > certain that it is on the physical media in a state from which
    > it can be accessed after a crash. If this is the intent, then
    > playing games with individual directories is not useful and
    > fsync() on the read/write file-descriptor actually updating the
    > file should be sufficient.

    We had a similar discussion along the lines of an MTA roughly a year
    ago, but without your (unquoted) objection that fsync() on a fiel
    without write permit should be impossible.

    The essence was that Linux 2.4 ext3fs and reiserfs guarantee that on
    fsync(), the file is recoverable from the place it was created, 2.2 was
    halfway there; but beware: only data=ordered or data=journal (in ext3fs,
    as beta patch for reiserfs from
    ftp.suse.com:/pub/people/mason/patches/data-logging/ <- from memory))
    will guarantee that your file contents are recoverable.

    This does not constitute any statement on JFS or XFS. I'm unaware of
    their characteristics in fsync and directory update issues.

    That aside, it would really useful to get this "hog a writer" issue
    ironed out either way, and that the illogical "fsync() a O_RDONLY" file
    be resolved somehow.

    For the data of users not acquainted with kernel intrinsics, the way
    things are now are most dangerous, and I'd really ask that Andrew
    Morton's dirsync() patches (where still necessary) and tool patches
    (chattr, mount) be deployed NOW and that -o dirsync (call it noasync for
    compatibility) be the default. A safety-speed tradeoff should only
    sacrifice safety at the explicit request and mke2fs should be told to
    generate ext3fs by default NOW.

    The argumentation that Linux leaves the choice of when to sync directory
    data to the application is nice, but not more, and having this as tuning
    option is fine, but to quote Wietse Venema "it's interesting to see that
    out of the box, Linux handles logging more securely (sync writes) than
    email (async directory updates)". And right he is.

    Is fsync()ing directories any portable?

    -- archived at: http://groups.google.com/groups?selm=89uj5c%242h2s%241%40FreeBSD.csie.NCTU.edu.tw&oe=utf-8&output=gplain

    --
    Matthias Andree
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:4.127 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site