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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
