Hello. [root@botva incoming]# btrfs fi defrag file-350mb [root@botva incoming]# filefrag file-350mb file-350mb: 132 extents found [root@botva incoming]# rsync --preallocate file-350mb test [root@botva incoming]# filefrag test test: 1 extent found The system is 2.6.37 with latest for-linus. Thanks. -- This message represents the official view of the voices in my head -- 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
Excerpts from Paul Komkoff''s message of 2011-01-19 14:58:28 -0500:> Hello. > > [root@botva incoming]# btrfs fi defrag file-350mb > [root@botva incoming]# filefrag file-350mb > file-350mb: 132 extents foundThe 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. -chris -- 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
On Wed, Jan 19, 2011 at 9:25 PM, Chris Mason <chris.mason@oracle.com> 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 :) -- This message represents the official view of the voices in my head -- 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
On Wed, Jan 19, 2011 at 4:31 PM, Paul Komkoff <i@stingr.net> wrote:> On Wed, Jan 19, 2011 at 9:25 PM, Chris Mason <chris.mason@oracle.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Excerpts from Paul Komkoff''s message of 2011-01-19 17:31:56 -0500:> On Wed, Jan 19, 2011 at 9:25 PM, Chris Mason <chris.mason@oracle.com> 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 :)Are you using compression? -chris -- 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
On Thu, Jan 20, 2011 at 9:38 PM, Chris Mason <chris.mason@oracle.com> wrote:> Are you using compression?No. -- This message represents the official view of the voices in my head -- 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