Re: [patch] fix the ext3 data=journal unmount bug

[Chris Mason]

On Fri, 2002-12-06 at 14:57, Stephen C. Tweedie wrote:
> Hi,
> 
> On Fri, 2002-12-06 at 19:45, Andrew Morton wrote:
> 
> > > I see what ext3 gains from your current patch in the unmount case, but
> > > the sync case is really unchanged because of interaction with kupdate.
> > 
> > True.  And I'd like /bin/sync to _really_ be synchronous because
> > I use `reboot -f' all the time.  Even though SuS-or-POSIX say that
> > sync() only needs to _start_ the IO.  That's rather silly.
> 
> But at the same time I'd like to avoid sync becoming serialised on its
> writes.  If you've got a lot of filesystems mounted, doing each
> filesystem's sync sequentially and synchronously is going to be a lot
> slower than allowing async syncs.  In other words, for sync(2) we really
> want async commit submission followed by a synchronous wait for
> completion.  And that's probably more churn than I'd like to see at this
> stage for 2.4.

The bulk of the sync(2) will be async though, since most of the io is
actually writing dirty data buffers out.  We already do that in two
stages.

For 2.5, if an FS really wanted a two stage sync for it's non-data
pages, it could put a locked page onto one of the lists that
sync_inodes(1) will catch and wait for.  There are lots of other ways of
course, but there's already a framework for sync to wait on pages.

For 2.4, an FS async sync function could toss a locked buffer head into
the locked buffer lru list, and unlock when the commit is complete.

Neither idea is as clean as a real aio interface, but all the
infrastructure is already there. 

Also, I think async sync support is a different feature than allowing
the FS to know the difference between kupdate periodic writes and
syncs/unmounts.

-chris