Re: [PATCH 1/2 v4] Btrfs: snapshot-aware defrag

[Liu Bo <bo.li.liu@oracle.com>]

On Sun, Nov 25, 2012 at 12:48:33PM +0900, Itaru Kitayama wrote:
> Hi Liubo:
> 
> At the relinking stage, in some situations, looking up the extent tree with
> the extent logical start objectid key from one of the old extents fails,
> but the found previous item's objectid + offset is exactly the original
> search objectid. As you say, usually old extents are retrieved from the
> extent tree without a problem, but if the Delayed or some other mechanisms
> change extents layout in the finish ordered IO function, we need to take
> care of those rejected extents, not simply returning ENOENT. What do you
> think?

Hi Itaru san,

Thanks for the suggestion.

It's all right to ignore ENOENT.

An extent stands for a range of space, which owns an item in extent tree.

If old extents' item is not found in the extent tree, i.e. rejected extents,
it means that this range of space is not shared by any snapshots(the extent refs is now 0),
and so it's safe.

So the worst case is that due to COW, a file and its snapshots share nothing
after some time, the defrag on the file won't change its snapshots, but this
can be solved when we always with autodefrag and snapshot-aware defrag.

thanks,
liubo