[lkml]   [2011]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v3] introduce sys_syncfs to sync a single file system
    On Mon, 14 Mar 2011 02:56:52 +0100 (CET)
    "Indan Zupancic" <> wrote:

    > On Sat, March 12, 2011 18:32, Greg KH wrote:
    > > On Fri, Mar 11, 2011 at 08:10:01PM -0600, Jonathan Nieder wrote:
    > >> Indan Zupancic wrote:
    > >>
    > >> > I'm not pushing for any official convention, just what seems good taste.
    > >>
    > >> In cases like this, conventions (consistency and best practices) are
    > >> very important.
    > >>
    > >> > Less code added, less bloat. Architecture independent, no need to update
    > >> > all system call tables everywhere (all archs, libc versions and strace).
    > >> > Two files changed, instead of 7 (which only hooks up x86).
    > >>
    > >> Thanks for explaining. Those do seem like good reasons to use a ioctl
    > >> instead of a new syscall.
    > >
    > > No, make it a syscall, it's more obvious and will be documented much
    > > better.
    > There is no such guarantee. Everyone seems to want to add this new syncfs,
    > but it's not even defined what it does. "Same as sync, but only on one fs"
    > is IMHO not good enough, because sync's behaviour is pretty badly documented,
    > and that's a system call. The sync_file_range argument effects are quite
    > well defined, on the other hand, unlike sync behaviour. You're right for
    > ioctls though.

    I think the semantics of sync are easily enough defined, even if
    they're not well-defined in the documentation: all data which was dirty
    at the time sync() was called will be written back and accessible when
    the sync() returns.

    I do agree that this should be a standalone syscall, not grafted into
    sync_file_range() or into an ioctl.

    That being said, we have two similar-looking-but-quite-different "sync"
    concepts in the kernel. One is "sync for data integrity" and the other
    is "sync to reduce the dirty memory load". The latter is not a data
    integrity thing - it is a resource management thing.

    There might one day be a requirement to be able to initiate a
    resource-management-style writeback against a whole filesystem. When
    that happens, we'll regret not having added a "mode" argument to

    Or maybe not - given that we're syncing the entire fs and that
    sync_filesystem() does the two-pass "write for data cleaning then write
    for data integrity" thing, it could be that a syncfs-for-data-cleaning
    operation has little performance benefit over a
    syncfs-for-data-integrity operation.

     \ /
      Last update: 2011-03-14 21:13    [W:0.030 / U:5.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site