[lkml]   [2002]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] sys_sync livelock fix
    On February 13, 2002 06:21 am, Bill Davidsen wrote:
    > On Tue, 12 Feb 2002, Andrew Morton wrote:
    > > IMO, the SuS definition sucks. We really do want to do our best to
    > > ensure that pending writes are committed to disk before sys_sync()
    > > returns. As long as that doesn't involve waiting until mid-August.
    > The current behaviour allows the system to hang forever waiting for
    > sync(2). In practice it does actually wait minutes on a busy system (df
    > has --no-sync for that reason) when there is no reason for that to happen.
    > I think that not only sucks worse, it's non-standard as well.

    Nothing sucks worse than losing your data. Let's concentrate on fixing
    shutdown, not breaking (linux) sync.

    > > For example, ext3 users get to enjoy rebooting with `sync ; reboot -f'
    > > to get around all those silly shutdown scripts. This very much relies
    > > upon the sync waiting upon the I/O.
    > Because people count on something broken we should keep the bug? You do
    > realize that the sync may NEVER finish?

    You do realize that if you lose your data you may NEVER get it back? ;-)

    > That's not in theory, I have news
    > servers which may wait overnight without finishing a "df" iwthout the
    > option.

    OK, what you're really saying is, we need a way to kill the sync process
    if it runs overtime, no?

    > > I mean, according to SUS, our sys_sync() implementation could be
    > >
    > > asmlinkage void sys_sync(void)
    > > {
    > > return;
    > > }
    > >
    > > Because all I/O is already scheduled, thanks to kupdate.
    > I think the wording is queued, and I would read that as "on the
    > elevator."

    Well now you're adding your own semantics to SuS, welcome to the party.
    I vote we keep the existing and-don't-come-back-until-you're-done Linux

    > Your example is a good example of bad practive, since even with
    > ext3 a program creating files quickly would lose data, even though the
    > directory structure is returned to a known state, without stopping the
    > writing processes the results are unknown.

    Huh? You know about journal commit, right?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:24    [W:0.024 / U:29.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site