![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2005-03-22 12:31 [from the cache] ©2003-2008 | ||||||||||