lkml.org 
[lkml]   [2009]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: vfs: Add MS_FLUSHONFSYNC mount flag
    From
    Date
    On Thu, 2009-02-12 at 15:30 -0600, Eric Sandeen wrote:
    > Jan Kara wrote:
    > > On Thu 12-02-09 11:13:37, Eric Sandeen wrote:
    >
    > ...
    >
    > >> Also that way if you have 8 partitions on a battery-backed blockdev, you
    > >> can tune it once, instead of needing to mount all 8 filesystems with the
    > >> new option.
    > > Yes, but OTOH we should give sysadmin a possibility to enable / disable
    > > it on just some partitions. I don't see a reasonable use for that but people
    > > tend to do strange things ;) and here isn't probably a strong reason to not
    > > allow them.
    > >
    > > Honza
    >
    > But nobody has asked for that, have they? So why offer it up a this point?
    >
    > They could use LD_PRELOAD to make fsync a no-op if they really don't
    > care for it, I guess... though that's not easily per-fs either.
    >
    > But do we really want to go out of our way to enable people to
    > short-circuit data integrity paths and then file bugs when their files
    > go missing? :)

    Well, it is just a matter of using safe defaults. IMHO, a scenario where
    the administrator wants to optimize writes to a certain partition and
    _explicitly_ clears MS_FLUSHONFSYNC on that superblock is not completely
    unreasonable.

    > (I guess the blockdev tunable is similarly dangerous, but it more
    > clearly meets the explicit need (writecache-safe devices))

    If distributions use sane defaults and we document the mount option or
    bdev tunable properly I guess it might make sense to allow system
    administrators to shoot themselves in the foot.

    (By the way, in this patch-set a patch for mount(8) is included.)

    - Fernando



    \
     
     \ /
      Last update: 2009-02-13 02:49    [W:2.562 / U:0.388 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site