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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 $? > 20That''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 foundThis 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. ---
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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... >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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''
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html