* BTRFS fails defragging
@ 2013-02-21 14:46 Swâmi Petaramesh
2013-02-21 15:01 ` Hugo Mills
2013-02-21 19:18 ` Martin Steigerwald
0 siblings, 2 replies; 6+ messages in thread
From: Swâmi Petaramesh @ 2013-02-21 14:46 UTC (permalink / raw)
To: BTRFS, Linux
Hi folks,
I'm using Ubuntu 12.10 Quantal with
# uname -r
3.5.0-24-generic
And it seems I cannot defrag :
# filefrag /boot/initrd.img-3.5.0-24-generic
/boot/initrd.img-3.5.0-24-generic: 3 extents found
# btrfs filesystem defrag /boot/initrd.img-3.5.0-24-generic
# echo $?
20
# filefrag /boot/initrd.img-3.5.0-24-generic
/boot/initrd.img-3.5.0-24-generic: 3 extents found
Any clue appreciated ;-)
TIA.
--
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BTRFS fails defragging
2013-02-21 14:46 BTRFS fails defragging Swâmi Petaramesh
@ 2013-02-21 15:01 ` Hugo Mills
2013-02-21 15:10 ` Swâmi Petaramesh
2013-02-21 19:18 ` Martin Steigerwald
1 sibling, 1 reply; 6+ messages in thread
From: Hugo Mills @ 2013-02-21 15:01 UTC (permalink / raw)
To: Swâmi Petaramesh; +Cc: BTRFS, Linux
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
On Thu, Feb 21, 2013 at 03:46:59PM +0100, Swâmi Petaramesh wrote:
> Hi folks,
>
> I'm using Ubuntu 12.10 Quantal with
> # uname -r
> 3.5.0-24-generic
>
> And it seems I cannot defrag :
>
> # filefrag /boot/initrd.img-3.5.0-24-generic
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
>
> # btrfs filesystem defrag /boot/initrd.img-3.5.0-24-generic
> # echo $?
> 20
That's a success. The return code for defrag is broken, and for
some reason returns 20 on success.
> # filefrag /boot/initrd.img-3.5.0-24-generic
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
This is pretty good. You can't guarantee that any given file will
be defragmented completely. I think if the file is large (bigger than
a block group), then it'll be split across the block group boundaries.
I'd say 3 fragments is pretty good, unless it's a couple of KiB in
size...
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Try everything once, except incest and folk-dancing. ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BTRFS fails defragging
2013-02-21 15:01 ` Hugo Mills
@ 2013-02-21 15:10 ` Swâmi Petaramesh
2013-02-21 16:10 ` Eric Sandeen
0 siblings, 1 reply; 6+ messages in thread
From: Swâmi Petaramesh @ 2013-02-21 15:10 UTC (permalink / raw)
To: Hugo Mills, BTRFS, Linux
Le 21/02/2013 16:01, Hugo Mills a écrit :
> That's a success. The return code for defrag is broken, and for some
> reason returns 20 on success.
Thanks for the quick reply Hugo. So should I script that "for now and
the future", $? 20 = OK ?
> This is pretty good. You can't guarantee that any given file will be
> defragmented completely. I think if the file is large (bigger than a
> block group), then it'll be split across the block group boundaries.
> I'd say 3 fragments is pretty good, unless it's a couple of KiB in
> size... Hugo.
Isn't filefrag supposed to report only non-consecutive fragments ?
If not, at which number of fragments would you advise me to defrag a file ?
(Another question would be : How to check directory fragmentation ?)
Something extremely weird happened here : I just ran filefrag -v twice
on this very file, and it gave me very different results... I don't
expect the file to have changed although, as this is an initramfs which
gets updated only when critical packages are - and no update of any kind
took place between the 2 very different reports... Any clue ?
Once :
# filefrag -v /boot/initrd.img-3.5.0-24-generic
Filesystem type is: 9123683e
File size of /boot/initrd.img-3.5.0-24-generic is 22809774 (5569 blocks,
blocksize 4096)
ext logical physical expected length flags
0 0 94048 128
1 128 94176 128
2 256 94304 128
3 384 94432 128
4 512 94560 128
5 640 94688 128
6 768 94816 128
7 896 94944 128
8 1024 95072 128
9 1152 95200 128
10 1280 95328 128
11 1408 95456 128
12 1536 95584 128
13 1664 95712 128
14 1792 127044 95840 128
15 1920 127172 128
16 2048 127300 128
17 2176 127428 128
18 2304 127556 128
19 2432 127684 128
20 2560 127812 128
21 2688 127940 128
22 2816 128068 128
23 2944 128196 128
24 3072 128324 128
25 3200 128452 128
26 3328 128580 128
27 3456 128708 128
28 3584 128836 128
29 3712 128964 128
30 3840 129092 128
31 3968 129220 128
32 4096 129348 128
33 4224 129476 128
34 4352 129604 128
35 4480 129732 128
36 4608 129860 128
37 4736 129988 128
38 4864 130116 128
39 4992 130244 128
40 5120 130372 128
41 5248 130500 128
42 5376 130628 128
43 5504 21832 130756 65 eof
/boot/initrd.img-3.5.0-24-generic: 3 extents found
...and then...:
# filefrag -v /boot/initrd.img-3.5.0-24-generic
Filesystem type is: 9123683e
File size of /boot/initrd.img-3.5.0-24-generic is 22809774 (5569 blocks,
blocksize 4096)
ext logical physical expected length flags
0 0 94048 1792
1 1792 127044 95840 3712
2 5504 21832 130756 65 eof
/boot/initrd.img-3.5.0-24-generic: 3 extents found
I'm puzzled...
--
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BTRFS fails defragging
2013-02-21 15:10 ` Swâmi Petaramesh
@ 2013-02-21 16:10 ` Eric Sandeen
2013-02-21 17:16 ` Hugo Mills
0 siblings, 1 reply; 6+ messages in thread
From: Eric Sandeen @ 2013-02-21 16:10 UTC (permalink / raw)
To: Swâmi Petaramesh; +Cc: Hugo Mills, BTRFS, Linux
On 2/21/13 9:10 AM, Swâmi Petaramesh wrote:
> Le 21/02/2013 16:01, Hugo Mills a écrit :
>> That's a success. The return code for defrag is broken, and for some
>> reason returns 20 on success.
>
> Thanks for the quick reply Hugo. So should I script that "for now and
> the future", $? 20 = OK ?
Heh:
static int cmd_defrag(int argc, char **argv)
{
<snip>
if (errors) {
fprintf(stderr, "total %d failures\n", errors);
exit(1);
}
return errors + 20;
}
what the . . . It's the only command in the file that adds
some random number to the 0 success return. I have no idea
what that could possibly be for.
Unless someone can document & explain the rationale for all these crazy
error values I think they need to be ripped out & sanitized.
For scripting I suppose I'd say "0 or 20 is OK"
-Eric
>> This is pretty good. You can't guarantee that any given file will be
>> defragmented completely. I think if the file is large (bigger than a
>> block group), then it'll be split across the block group boundaries.
>> I'd say 3 fragments is pretty good, unless it's a couple of KiB in
>> size... Hugo.
>
> Isn't filefrag supposed to report only non-consecutive fragments ?
>
> If not, at which number of fragments would you advise me to defrag a file ?
>
> (Another question would be : How to check directory fragmentation ?)
>
> Something extremely weird happened here : I just ran filefrag -v twice
> on this very file, and it gave me very different results... I don't
> expect the file to have changed although, as this is an initramfs which
> gets updated only when critical packages are - and no update of any kind
> took place between the 2 very different reports... Any clue ?
>
> Once :
>
> # filefrag -v /boot/initrd.img-3.5.0-24-generic
> Filesystem type is: 9123683e
> File size of /boot/initrd.img-3.5.0-24-generic is 22809774 (5569 blocks,
> blocksize 4096)
> ext logical physical expected length flags
> 0 0 94048 128
> 1 128 94176 128
> 2 256 94304 128
> 3 384 94432 128
> 4 512 94560 128
> 5 640 94688 128
> 6 768 94816 128
> 7 896 94944 128
> 8 1024 95072 128
> 9 1152 95200 128
> 10 1280 95328 128
> 11 1408 95456 128
> 12 1536 95584 128
> 13 1664 95712 128
> 14 1792 127044 95840 128
> 15 1920 127172 128
> 16 2048 127300 128
> 17 2176 127428 128
> 18 2304 127556 128
> 19 2432 127684 128
> 20 2560 127812 128
> 21 2688 127940 128
> 22 2816 128068 128
> 23 2944 128196 128
> 24 3072 128324 128
> 25 3200 128452 128
> 26 3328 128580 128
> 27 3456 128708 128
> 28 3584 128836 128
> 29 3712 128964 128
> 30 3840 129092 128
> 31 3968 129220 128
> 32 4096 129348 128
> 33 4224 129476 128
> 34 4352 129604 128
> 35 4480 129732 128
> 36 4608 129860 128
> 37 4736 129988 128
> 38 4864 130116 128
> 39 4992 130244 128
> 40 5120 130372 128
> 41 5248 130500 128
> 42 5376 130628 128
> 43 5504 21832 130756 65 eof
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
>
> ...and then...:
>
> # filefrag -v /boot/initrd.img-3.5.0-24-generic
> Filesystem type is: 9123683e
> File size of /boot/initrd.img-3.5.0-24-generic is 22809774 (5569 blocks,
> blocksize 4096)
> ext logical physical expected length flags
> 0 0 94048 1792
> 1 1792 127044 95840 3712
> 2 5504 21832 130756 65 eof
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
>
> I'm puzzled...
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BTRFS fails defragging
2013-02-21 16:10 ` Eric Sandeen
@ 2013-02-21 17:16 ` Hugo Mills
0 siblings, 0 replies; 6+ messages in thread
From: Hugo Mills @ 2013-02-21 17:16 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Swâmi Petaramesh, BTRFS, Linux
[-- Attachment #1: Type: text/plain, Size: 5275 bytes --]
On Thu, Feb 21, 2013 at 10:10:57AM -0600, Eric Sandeen wrote:
> On 2/21/13 9:10 AM, Swâmi Petaramesh wrote:
> > Le 21/02/2013 16:01, Hugo Mills a écrit :
> >> That's a success. The return code for defrag is broken, and for some
> >> reason returns 20 on success.
> >
> > Thanks for the quick reply Hugo. So should I script that "for now and
> > the future", $? 20 = OK ?
>
> Heh:
>
> static int cmd_defrag(int argc, char **argv)
> {
>
> <snip>
> if (errors) {
> fprintf(stderr, "total %d failures\n", errors);
> exit(1);
> }
>
> return errors + 20;
> }
>
> what the . . . It's the only command in the file that adds
> some random number to the 0 success return. I have no idea
> what that could possibly be for.
It's been a minor pain in the arse for some time.
> Unless someone can document & explain the rationale for all these crazy
> error values I think they need to be ripped out & sanitized.
I asked about the rationale a couple of years ago. IIRC, it was
simply to try to ensure that they were all unique. They're
undocumented, and always have been.
Hugo.
> For scripting I suppose I'd say "0 or 20 is OK"
>
> -Eric
>
> >> This is pretty good. You can't guarantee that any given file will be
> >> defragmented completely. I think if the file is large (bigger than a
> >> block group), then it'll be split across the block group boundaries.
> >> I'd say 3 fragments is pretty good, unless it's a couple of KiB in
> >> size... Hugo.
> >
> > Isn't filefrag supposed to report only non-consecutive fragments ?
> >
> > If not, at which number of fragments would you advise me to defrag a file ?
> >
> > (Another question would be : How to check directory fragmentation ?)
> >
> > Something extremely weird happened here : I just ran filefrag -v twice
> > on this very file, and it gave me very different results... I don't
> > expect the file to have changed although, as this is an initramfs which
> > gets updated only when critical packages are - and no update of any kind
> > took place between the 2 very different reports... Any clue ?
> >
> > Once :
> >
> > # filefrag -v /boot/initrd.img-3.5.0-24-generic
> > Filesystem type is: 9123683e
> > File size of /boot/initrd.img-3.5.0-24-generic is 22809774 (5569 blocks,
> > blocksize 4096)
> > ext logical physical expected length flags
> > 0 0 94048 128
> > 1 128 94176 128
> > 2 256 94304 128
> > 3 384 94432 128
> > 4 512 94560 128
> > 5 640 94688 128
> > 6 768 94816 128
> > 7 896 94944 128
> > 8 1024 95072 128
> > 9 1152 95200 128
> > 10 1280 95328 128
> > 11 1408 95456 128
> > 12 1536 95584 128
> > 13 1664 95712 128
> > 14 1792 127044 95840 128
> > 15 1920 127172 128
> > 16 2048 127300 128
> > 17 2176 127428 128
> > 18 2304 127556 128
> > 19 2432 127684 128
> > 20 2560 127812 128
> > 21 2688 127940 128
> > 22 2816 128068 128
> > 23 2944 128196 128
> > 24 3072 128324 128
> > 25 3200 128452 128
> > 26 3328 128580 128
> > 27 3456 128708 128
> > 28 3584 128836 128
> > 29 3712 128964 128
> > 30 3840 129092 128
> > 31 3968 129220 128
> > 32 4096 129348 128
> > 33 4224 129476 128
> > 34 4352 129604 128
> > 35 4480 129732 128
> > 36 4608 129860 128
> > 37 4736 129988 128
> > 38 4864 130116 128
> > 39 4992 130244 128
> > 40 5120 130372 128
> > 41 5248 130500 128
> > 42 5376 130628 128
> > 43 5504 21832 130756 65 eof
> > /boot/initrd.img-3.5.0-24-generic: 3 extents found
> >
> > ...and then...:
> >
> > # filefrag -v /boot/initrd.img-3.5.0-24-generic
> > Filesystem type is: 9123683e
> > File size of /boot/initrd.img-3.5.0-24-generic is 22809774 (5569 blocks,
> > blocksize 4096)
> > ext logical physical expected length flags
> > 0 0 94048 1792
> > 1 1792 127044 95840 3712
> > 2 5504 21832 130756 65 eof
> > /boot/initrd.img-3.5.0-24-generic: 3 extents found
> >
> > I'm puzzled...
> >
>
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I get nervous when I see words like 'mayhaps' in a novel, ---
because I fear that just round the corner
is lurking 'forsooth'
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BTRFS fails defragging
2013-02-21 14:46 BTRFS fails defragging Swâmi Petaramesh
2013-02-21 15:01 ` Hugo Mills
@ 2013-02-21 19:18 ` Martin Steigerwald
1 sibling, 0 replies; 6+ messages in thread
From: Martin Steigerwald @ 2013-02-21 19:18 UTC (permalink / raw)
To: linux-btrfs; +Cc: Swâmi Petaramesh
Am Donnerstag, 21. Februar 2013 schrieb Swâmi Petaramesh:
> Hi folks,
>
> I'm using Ubuntu 12.10 Quantal with
> # uname -r
> 3.5.0-24-generic
>
> And it seems I cannot defrag :
>
> # filefrag /boot/initrd.img-3.5.0-24-generic
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
>
> # btrfs filesystem defrag /boot/initrd.img-3.5.0-24-generic
> # echo $?
> 20
>
> # filefrag /boot/initrd.img-3.5.0-24-generic
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
>
> Any clue appreciated ;-)
Make sure to wait long enough or issue the "sync" command.
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> ls -lh soprano-virtuoso.db
-rw------- 1 martin martin 1,6G Feb 21 20:10 soprano-virtuoso.db
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> date ; filefrag soprano-virtuoso.db
Do 21. Feb 20:16:27 CET 2013
soprano-virtuoso.db: 58875 extents found
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> date ; btrfs fi defrag soprano-virtuoso.db
Do 21. Feb 20:16:39 CET 2013
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend#20> date ; filefrag soprano-virtuoso.db
Do 21. Feb 20:16:48 CET 2013
soprano-virtuoso.db: 22424 extents found
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> date ; filefrag soprano-virtuoso.db
Do 21. Feb 20:16:50 CET 2013
soprano-virtuoso.db: 22424 extents found
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> sync
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> date ; filefrag soprano-virtuoso.db
Do 21. Feb 20:16:54 CET 2013
soprano-virtuoso.db: 960 extents found
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
(here "fragmentation" might not be real fragmentation always due to the way
LZO compression works in BTRFS, AFAIR Hugo told me)
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-02-21 19:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-21 14:46 BTRFS fails defragging Swâmi Petaramesh
2013-02-21 15:01 ` Hugo Mills
2013-02-21 15:10 ` Swâmi Petaramesh
2013-02-21 16:10 ` Eric Sandeen
2013-02-21 17:16 ` Hugo Mills
2013-02-21 19:18 ` Martin Steigerwald
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox