* btrfs defrag: how does it work?
@ 2011-01-19 19:58 Paul Komkoff
2011-01-19 21:25 ` Chris Mason
0 siblings, 1 reply; 6+ messages in thread
From: Paul Komkoff @ 2011-01-19 19:58 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs defrag: how does it work?
2011-01-19 19:58 btrfs defrag: how does it work? Paul Komkoff
@ 2011-01-19 21:25 ` Chris Mason
2011-01-19 22:31 ` Paul Komkoff
0 siblings, 1 reply; 6+ messages in thread
From: Chris Mason @ 2011-01-19 21:25 UTC (permalink / raw)
To: Paul Komkoff; +Cc: linux-btrfs
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 found
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.
-chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs defrag: how does it work?
2011-01-19 21:25 ` Chris Mason
@ 2011-01-19 22:31 ` Paul Komkoff
2011-01-19 22:49 ` Mitch Harder
2011-01-20 21:38 ` Chris Mason
0 siblings, 2 replies; 6+ messages in thread
From: Paul Komkoff @ 2011-01-19 22:31 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-btrfs
On Wed, Jan 19, 2011 at 9:25 PM, Chris Mason <chris.mason@oracle.com> w=
rote:
> 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
> 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 :)
--=20
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs defrag: how does it work?
2011-01-19 22:31 ` Paul Komkoff
@ 2011-01-19 22:49 ` Mitch Harder
2011-01-20 21:38 ` Chris Mason
1 sibling, 0 replies; 6+ messages in thread
From: Mitch Harder @ 2011-01-19 22:49 UTC (permalink / raw)
To: Paul Komkoff; +Cc: Chris Mason, linux-btrfs
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. =A0It 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 an=
d
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs defrag: how does it work?
2011-01-19 22:31 ` Paul Komkoff
2011-01-19 22:49 ` Mitch Harder
@ 2011-01-20 21:38 ` Chris Mason
2011-01-22 13:38 ` Paul Komkoff
1 sibling, 1 reply; 6+ messages in thread
From: Chris Mason @ 2011-01-20 21:38 UTC (permalink / raw)
To: Paul Komkoff; +Cc: linux-btrfs
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. =C2=A0It opens up the file=
and
> > recows all the extents and then the delayed allocation code jumps i=
n 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 a=
nd
> > you should see the results of the defrag sooner.
>=20
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs defrag: how does it work?
2011-01-20 21:38 ` Chris Mason
@ 2011-01-22 13:38 ` Paul Komkoff
0 siblings, 0 replies; 6+ messages in thread
From: Paul Komkoff @ 2011-01-22 13:38 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-01-22 13:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-19 19:58 btrfs defrag: how does it work? Paul Komkoff
2011-01-19 21:25 ` Chris Mason
2011-01-19 22:31 ` Paul Komkoff
2011-01-19 22:49 ` Mitch Harder
2011-01-20 21:38 ` Chris Mason
2011-01-22 13:38 ` Paul Komkoff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).