On 10/26/2012 09:56 AM, Miao Xie wrote: >> I can see the potential improvements brought by flushing inodes this way. >> > >> > But I don't think it makes much sense by making waiting process multi-task, >> > since even we spread wait order extents into different cpus, they just >> > occpied >> > the cpu and went on waiting and scheduled then, I mean, the bottleneck is >> > on >> > what we're waiting for. > Thanks for your comment, I think only btrfs_run_ordered_operations(root, 0) > needn't > wait for the works, the others must wait. > > The first reason is to avoid changing the semantic of those tree function. > The second > reason is we have to wait for the completion of all works, if not, the file > data in > snapshots may be different with the source suvolumes because the flush may > not end > before the snapshot creation. >
Yes, it's right that they must wait for all workers to finish. But I don't mean that(sorry for my confusing words). IMO we don't need to let *btrfs_wait_ordered_extents()* run as multi-task. thanks, liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
