BTRFS fails defragging

Linux Btrfs filesystem development
 help / color / mirror / Atom feed

* 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