On Wed, Jan 19, 2011 at 4:31 PM, Paul Komkoff <i@xxxxxxxxxx> wrote: > On Wed, Jan 19, 2011 at 9:25 PM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: >> The defrag code doesn't actually defrag. It opens up the file and >> recows all the extents and then the delayed allocation code jumps in and >> 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 and >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
