lkml.org 
[lkml]   [2002]   [Dec]   [6]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 06 Dec 2002 11:45:19 -0800
FromAndrew Morton <>
SubjectRe: [patch] fix the ext3 data=journal unmount bug
Chris Mason wrote:
> 
> On Fri, 2002-12-06 at 14:12, Andrew Morton wrote:
> >
> > It won't.  There isn't really a sane way of doing this properly unless
> > we do something like:
> >
> > 1) Add a new flag to the superblock
> > 2) Set that flag against all r/w superblocks before starting the sync
> > 3) Use that flag inside the superblock walk.
> >
> > That would provide a reasonable solution, but I don't believe we
> > need to go to those lengths in 2.4, do you?
> 
> Grin, I'm partial to changing sync_supers to allow the FS to leave
> s_dirt set in its write_super call.

That doesn't sound like a simplification ;)

> 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.

> Other filesystems trying to use the sync_fs() call might think adding
> one is enough to always get called on sync, and I think that will lead
> to unreliable sync implementations.

OK.  How about we do it that way in in 2.5 and then look at a backport?
With the steps I propose above, filesystems which don't implement
sync_fs would see no changes, so it should be safe.
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:31    [from the cache]
©2003-2008