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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.