On Mon, Oct 26, 2009 at 10:21:52AM -0700, Joel Fernandes wrote: > Hi Josef, Your analysis makes perfect sense. Thank you so much. > > Another question, what could explain the slowness in data=ordered > mode? I believe everything is asynchronous right? various lists are > maintained, and kjournald keeps checking theses lists and flushing > data before metadata written and marked dirty as you said. Is the > slowness because the flushing of data is done earlier than required > unlike when done by pdflush which waits for a certain amount of time? > I'm not sure what slowness you are talking about, but I will assume you mean the slowness of committing a transaction. Basically everything that has happened since the last journal commit must be taken care of. So all data that has been written needs to be written out synchronously, and then its metadata written to the journal, and then we can let things start going again while the metadata is written to where its supposed to asynchronously. The key part of that is _all_ data needs to be written out. This is slow compared to Ext4 because with Ext4 we have delayed allocation, so even though we may have dirtied alot of pages since the last transaction has occured, they may not have been allocated yet, so no metadata has been changed yet, so we don't have to force the flushing of the data out to disk, so the journal commit takes much less time because there is much less work to do. I hope that answers your question. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
