On Tue, 12 Feb 2002, Andrew Morton wrote:
> Alan Cox wrote:
> >
> > > I don't see why it should be different for applications
> > > that write data after sync has started.
> >
> > The guarantee about data written _before_ the sync started is also being
> > broken unless I misread the code
>
> That would be very broken.
>
> The theory is: newly dirtied buffers are added at the "new"
> end of the LRU. write_some_buffers() starts at the "old"
> end of the LRU.
>
> So if write_unlock_buffers writes out the "oldest"
> nr_buffers_type[BUF_DIRTY] buffers, then it knows
> that it has written out everything which was dirty
> at the time it was called.
>
> Or did I miss something?
Alan is right about the first version of the patch not getting all dirty
buffers I haven't looked at the latest version but the change seems to be
correct. Other than that I agree that "everything which was dirty at the
time it was called" is exactly right, what the user expects and what the
SuS says.
However, after thinksing about the SuS, it says (paraphrase) "queued but
not necessarily written." So if I read that right sync() is intended to be
a non-blocking operation. We can do that, but there is one thing which
must be added: with all the various patches which hack the elevator code,
we need a flag which says "do not add anything more to this pass." That
makes the SuS implementation of sync() possible, and makes the completion
of the operation deterministic. When all the dirty blocks are written the
operation is done.
-- bill davidsen <davidsen@tmr.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:52 EST