On Fri, 25 Apr 2008, Zach Brown wrote:
> We still have the same inode, and it has the same size, but its extent
> items look very different. The extent for the first 64k looks much the
> same. It references the old 64m extent on disk. But see the 'nr
> 65536', it only maps 64k of that 64m into the file. Then we have the 4k
> extent that we just wrote. Then we have another reference to that 64m
> extent but for the remaining data after the new 4k.
Is there anything in the defragger (or whatever) that looks for minimally
referenced extents? Once can imagine a situation where only a small piece
of a large extent is remains referenced, but that information is buried in
the forward reference(s).
> debug-tree is fantastic, but it can be kind of intimidating if you don't
> already know what all the numbers mean :). Reducing the barrier to
Yep. Although in my case, the biggest stumbling block was realizing that
the key type
> item 3 key (258 12 0) itemoff 2652 itemsize 41
^^
is in printed in hex for some reason. Der.
sage
_______________________________________________
Btrfs-devel mailing list
[email protected]
http://oss.oracle.com/mailman/listinfo/btrfs-devel
