[lkml]   [2009]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.29 -mm merge plans

    > > > I'm not sure this is a good idea. Concurrent syncs are a bad idea
    > > > to start with and we should just synchronyze do_sync completely.
    > > > sync_filesystems as one of the main components of do_sync already
    > > > is synchronized in that way, and taking that to a higher level would
    > > > get rid of all the worries about concurrent syncs.
    > >
    > > Yes, single-threading sys_sync() would fix the problem which that patch
    > > addresses.
    > >
    > > However there are a lot of performance and correctness issues around
    > > sys_sync()-versus-fsync(), etc for which such a simple fix won't be
    > > acceptable.
    > fsync should really not much interac with sync at that level. While
    > they both end up at same primitives at the lowest level those aren't
    > the ones we're trying to protect against. I'm currently in the process
    > of a major rework of sys_sync/do_sync to make it work properly for
    > modern filesystems and the global synchronization was one of the first
    > things I did..
    > So if you have any workloads where that causes a problem please send
    > them my way. Not that I can really thing of them, given the global
    > nature of sys_sync I can't see any benefit of doing multiple of these
    > in parallel.

    I did play with fsync() a bit, and realized it mostly does not
    work. (Yes, I did physically unplug the media). I have some scripts,
    and am currently converting them to nbd so that I will not have to
    physically pull anything.

    Jack has some ext2 fix provoked by those tests...
    (cesky, pictures)

     \ /
      Last update: 2009-01-10 11:15    [W:0.023 / U:0.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site