On Wed, Jan 19, 2011 at 4:31 PM, Paul Komkoff [off-list ref] wrote:

On Wed, Jan 19, 2011 at 9:25 PM, Chris Mason [off-list ref]=

 wrote:

quoted

The defrag code doesn't actually defrag. =A0It opens up the file and
recows all the extents and then the delayed allocation code jumps in=

 and

quoted

makes the biggest possible extent that it can.

The reason why you're still seeing extents after running the defrag
command is because the file hasn't been written yet, so the delayed
allocation code hasn't kicked in.

If you use btrfs fi defrag -f it'll trigger writeback on the file an=

d

quoted

you should see the results of the defrag sooner.

I tried, and just tried it again, with the same file. I even tried
doing btrfs fi sync in random order. No matter what I do, it's still
132 extents :)
--

Is it possible that this patch is causing this behavior?:

http://www.spinics.net/lists/linux-btrfs/msg03110.html

It appears to me that when a relocation is performed (as is done with
defragmentation), that this patch limits the extent size with the
newly introduced "#define MAX_EXTENTS 128".
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html