[lkml]   [2002]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] sys_sync livelock fix
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

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.

I have seen shutdown hang many times, and I have to wonder if the shutdown
script is waiting for a process which is in some kind of write loop, while
the process ignores KILL signals. Don't know, don't claim I do, but I
see no reason for a sync() to handle more than current dirty blocks.

My opinion, but I hope yours. Fewer hangs and better performance is a
compromise I can accept.

bill davidsen <>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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.083 / U:2.052 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site