All of lore.kernel.org
 help / color / mirror / Atom feed
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...
> 


  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.