From: Eric Sandeen <sandeen@redhat.com>
To: "Swâmi Petaramesh" <swami@petaramesh.org>
Cc: Hugo Mills <hugo@carfax.org.uk>,
"BTRFS, Linux" <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS fails defragging
Date: Thu, 21 Feb 2013 10:10:57 -0600 [thread overview]
Message-ID: <51264711.1010804@redhat.com> (raw)
In-Reply-To: <512638F6.3090305@petaramesh.org>
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...
>
next prev parent reply other threads:[~2013-02-21 16:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2013-02-21 17:16 ` Hugo Mills
2013-02-21 19:18 ` Martin Steigerwald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51264711.1010804@redhat.com \
--to=sandeen@redhat.com \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=swami@petaramesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox