All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Andrew Morton <akpm@zip.com.au>,
	lkml <linux-kernel@vger.kernel.org>,
	viro@math.psu.edu
Subject: Re: [patch] sys_sync livelock fix
Date: Tue, 12 Feb 2002 22:46:54 -0500	[thread overview]
Message-ID: <3C69E1AE.B225A392@mandrakesoft.com> (raw)
In-Reply-To: <Pine.LNX.3.96.1020212220340.8017A-100000@gatekeeper.tmr.com>

Bill Davidsen wrote:
> 
> On Wed, 13 Feb 2002, Alan Cox wrote:
> 
> > > > Whats wrong with sync not terminating when there is permenantly I/O left ?
> > > > Its seems preferably to suprise data loss
> > >
> > > Hard call.  What do we *want* sync to do?
> >
> > I'd rather not change the 2.4 behaviour - just in case. For 2.5 I really
> > have no opinion either way if SuS doesn't mind
> 
> Alan, I think you have this one wrong, although SuS seems to have it wrong
> as well, and if Linux did what SuS said there would be no problem.
> 
> - What SuS seems to say is that all dirty buffers will queued for physical
>   write. I think if we did that the livelock would disappear, but data
>   integrity might suffer.
> - sync() could be followed by write() at the very next dispatch, and it
>   was never intended to be the last call after which no writes would be
>   done. It is a point in time.
> - the most common use of sync() is to flush data write to all files of the
>   current process. If there was a better way to do it which was portable,
>   sync() would be called less. I doubt there are processes which alluse
>   that no write will be done after sync() returns.
> - since sync() can't promise "no new writes" why try to make it do so? It
>   should mean "write current sirty buffers" and that's far more than SuS
>   requires.
> 
> I don't think benchmarks are generally important, but in this case the
> benchmark reveals that we have been implementing a system call in a way
> which not only does more than SuS requires, but more than the user
> expects. To leave it trying to do even more than that seems to have no
> benefit and a high (possible) cost.

Yow, your message inspired me to re-read SuSv2 and indeed confirm,
sync(2) schedules I/O but can return before completion, while
fsync(2) schedules I/O and waits for completion.

So we need to implement system call checkpoint(2) ?  schedule I/O,
introduce an I/O barrier, then sleep until that I/O barrier and all I/O
scheduled before it occurs.

	Jeff




-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

  reply	other threads:[~2002-02-13  3:47 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-12 23:13 [patch] sys_sync livelock fix Andrew Morton
2002-02-12 23:31 ` Alan Cox
2002-02-12 23:22   ` Andrew Morton
2002-02-13  0:28     ` Alan Cox
2002-02-13  3:28       ` Bill Davidsen
2002-02-13  3:46         ` Jeff Garzik [this message]
2002-02-13 15:11           ` Daniel Phillips
2002-02-13 22:24             ` Bill Davidsen
2002-02-13 22:41               ` Mike Fedyk
2002-02-14  0:26               ` Daniel Phillips
2002-02-14  0:37                 ` Andrew Morton
2002-02-14  0:49                   ` Daniel Phillips
2002-02-14  0:53                     ` Andrew Morton
2002-02-14  1:27                       ` Daniel Phillips
2002-02-14  1:29                         ` Andrew Morton
2002-02-14  1:59                     ` Mike Fedyk
2002-02-14  2:07                       ` Daniel Phillips
2002-02-13 23:31             ` Rob Landley
2002-02-14  0:44               ` Daniel Phillips
2002-02-12 23:29   ` Rik van Riel
2002-02-13  0:25     ` Alan Cox
2002-02-13  0:15       ` Rik van Riel
2002-02-13  0:36         ` Alan Cox
2002-02-13  0:36           ` Rik van Riel
2002-02-13  0:39           ` Andrew Morton
2002-02-13  3:42             ` Bill Davidsen
2002-02-13  3:54             ` Bill Davidsen
2002-02-13  4:01               ` Jeff Garzik
2002-02-13  4:53                 ` Bill Davidsen
2002-02-13 15:17                 ` Daniel Phillips
2002-02-13  4:29               ` Andrew Morton
2002-02-13  5:21                 ` Bill Davidsen
2002-02-13  5:35                   ` Andrew Morton
2002-02-18  2:29                     ` Bill Davidsen
2002-02-13 14:09                   ` bill davidsen
2002-02-13 15:29                   ` Daniel Phillips
2002-02-13 22:53                     ` Bill Davidsen
2002-02-14  0:33                       ` Daniel Phillips
2002-02-13  1:36 ` What is a livelock? (was: [patch] sys_sync livelock fix) Olaf Dietsche
2002-02-13  1:56   ` Andrew Morton
2002-02-13  2:30     ` Olaf Dietsche
2002-02-13  2:39       ` Andrew Morton
2002-02-13 16:19         ` Olaf Dietsche
2002-02-13  2:52       ` William Lee Irwin III
2002-02-18 22:19       ` David Schwartz
2002-02-13  2:33   ` Rob Landley
  -- strict thread matches above, loose matches on Subject: below --
2002-02-13  9:18 [patch] sys_sync livelock fix Andries.Brouwer
2002-02-14  0:57 Andries.Brouwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C69E1AE.B225A392@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.