On Wed 06-07-16 10:27:23, Ted Tso wrote: > On Wed, Jul 06, 2016 at 02:52:28PM +0200, Jan Kara wrote: > > > Starting another transaction while we are waiting for earlier > > > transaction to lock down is going to be problematic, since while there > > > are still handles active on the first transaction, they could still be > > > modifying metadata blocks. And while that's happening, we can't allow > > > any new handles associated with the second transaction to start > > > modifying metadata blocks. > > > > Well, we can. We just have to make sure we snapshot the contents that > > should be committed before we modify it from the new transaction. We > > already do this when we are committing block and need to modify it in the > > running transaction at the same time. Obviously allowing this logic to > > trigger earlier will lead to higher memory overhead and allocation, > > copying, and freeing of block snapshots isn't free either so it will need > > careful benchmarking. > > Consider the following sequence: > > Start handle A attached to txn #42 > > <Start Commiting transaction #42> > > Start handle B attached to tnx #43 > Call get_write_access on block bitmap #100 > Modify block bitmap #100 > journal_dirty_metadata for #100 > > Call get_write_access on block bitmap #100 > Modify block bitmap #100 > journal_dirty_metadata for #100 > > > Snapshotting the block bitmap at when handle B calls > get_write_access() won't help, because if handle B starts modifying > the block bitmap, and *then* handle A starts trying to modify the same > block bitmap, what do we do? > > You could make handle A make the same logical modification in both the > copy of metadata block associated with first transaction (#42) as well > as the copy of the metadata block associated with the second > transaction (#43), and for an allocation bitmap maybe it's even > doable. > > But consider the even more hairy case where handle A and handle B are > both modifying an inline xattr, and handle B has to convert spill some > of the extended attribute contents to an external xattr block. Now > when handle A makes some other xattr change, the change it needs to > make for transaction #42 might be very different from the one for > transaction #43. Yup, good point. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- 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
