On 05/10/2012 01:29 AM, David Sterba wrote: > On Fri, Apr 27, 2012 at 09:44:13AM +0800, Liu Bo wrote: >> Let's take the above case: >> 0k 20k >> | --- extent --- | >> | - A - | >> 1k 19k >> >> And we assume that this extent starts from disk_bytenr on its FS logical offset. >> >> By splitting the [0k, 20k) extent, we'll get three delayed refs into the delayed-ref rbtree: >> a) [0k, 20k), in which only [disk_bytenr+1k, disk_bytenr+19k) will be freed at the end. >> b) [0k, 1k), which will _not_ allocate a new extent but use the remained space of [0k, 20k). >> c) [19k, 20k), ditto. >> >> And another ref [1k,19k) will get a new allocated space by our normal endio routine. >> >> What I want is >> free [0k, 20k), set this range DIRTY in the pinned_extents tree. >> alloc [0k, 1k), clear this range DIRTY in the pinned_extents tree. >> alloc [19k, 20k), ditto. >> >> However, in my stress test, this three refs may not be ordered by a)->b)->c), but b)->a)->c) instead. >> That would be a problem, because it will confuse our space_info's counter: bytes_reserved, bytes_pinned. > > Do you have an idea why the ordering may become broken? If it's a race, > it might be better to fix it instead of adding a new bit to extent > flags. > These refs are well managed in the delayed_ref rbtree, but processing these refs can be multi-threads, so the ordering is not ensured to be sequenced since the original design thinks each ref is independent. Any thoughts? :) thanks, liubo > > david > -- > 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 > -- 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
