On Mon, Aug 19, 2013 at 10:31:15AM +0800, Miao Xie wrote: > On wed, 14 Aug 2013 11:41:00 -0400, Josef Bacik wrote: > > I added a patch where we started taking the ordered operations mutex when we > > waited on ordered extents. We need this because we splice the list and process > > it, so if a flusher came in during this scenario it would think the list was > > empty and we'd usually get an early ENOSPC. The problem with this is that this > > lock is used in transaction committing. So we end up with something like this > > > > Transaction commit > > -> wait on writers > > > > Delalloc flusher > > -> run_ordered_operations (holds mutex) > > ->wait for filemap-flush to do its thing > > > > flush task > > -> cow_file_range > > ->wait on btrfs_join_transaction because we're commiting > > > > some other task > > -> commit_transaction because we notice trans->transaction->flush is set > > -> run_ordered_operations (hang on mutex) > > Sorry, I can not understand this explanation. As far as I know, if the flush task > waits on btrfs_join_transaction(), it means the transaction is under commit > (state = TRANS_STATE_COMMIT_DOING), and all the external writers(TRANS_START/TRANS_ATTACH/ > TRANS_USERSPACE) have quitted the current transaction, so no one would try to call > run_ordered_operations(). > > Could you show us the reproduce steps? > Sorry I wrote the wrong thing for the delalloc flusher, that should be ->btrfs_wait_ordered_extents (holds ordered operations mutex) -> wait for filemap-flush to do its thing That should make it clearer. I reproduced it running xfstests generic/224. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
