On 16 February 2010 19:48, <tytso@xxxxxxx> wrote: > On Tue, Feb 16, 2010 at 02:10:39PM +0100, Jan Kara wrote: >> Actually, stalling on a transaction in LOCKED state does have a negative >> impact on the filesystem performance. But it's hard to avoid it. The >> transaction is in LOCKED state while we've decided it needs a commit but >> there are still tasks which have handle to it and are adding new metadata >> buffers to it. So this transaction is effectively still running and we >> cannot start a next transaction because then we'd have two running >> transactions and the journalling logic isn't able to handle that. > > This is also why we try to avoid staying in LOCKED state for very > long.... and why increasing the journal size can help performance > (since if we get ourselves into trouble where are forced to do a > journal checkpoint, we can end up stalling all file system updates for > a non-trivial amount of time). > > So changes that increase the amount of time that we spend in LOCKED > are going to be really bad, especially if you have one thread which is > frequently calling fsync() (for example, like Firefox, which can be > *very* fsync() happy) and another thread which is doing lots of file > creates and deletes. Each fsync() will force a transaction commit, > and if you have to stop all transaction updates while the delayed > allocation blocks are getting resolved, life can really get bad. Okay. It seems that there is no easy way to solve this. Probably, the personality flag based solution is more appropriate. Still, as we need this mode of operation for our further analysis, for now we will go with the same design to implement alloc_on_commit and see how can we optimize it and how much negative impact it has. Will update you on this. Thank you very much for the help. Regards, Kailas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
