On Fri, 2002-12-06 at 16:22, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, 2002-12-06 at 20:34, Chris Mason wrote:
>
> > 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.
>
> Not with data journaling. That's the whole point: the VFS assumes too
> much about where the data is being written, when.
But with data journaling, there's a limited amount data pending that
needs to be sent to the log. It isn't like the data pages in the
data=writeback, where there might be gigs and gigs worth of pages.
Most data=journal setups are for synchronous writes, where the
transactions will be small, so sending things to the log won't take
long.
>
> > For 2.5, if an FS really wanted a two stage sync for it's non-data
> > pages
>
> But it's data that is the problem. For sync() semantics,
> data-journaling only requires that the pages have hit the journal. For
> umount, it is critical that we complete the final writeback before
> destroying the inode lists.
Well, I was trying to find a word for pages involved w/the journal and
failed ;-) My only real point is we can add an async sync without
changing the way supers get processed.
It seems like a natural progression to start adding journal address
spaces to deal with this instead of extra stuff in the super code, where
locking and super flag semantics make things sticky.
-chris
-
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 : Sat Dec 07 2002 - 22:00:28 EST