Heyho! Just a first impression report from a pure user. I''ve started to play around with btrfs a bit, without using any btrfs-specific features so far, though. 700G, ca. 1/2 full, tons of small files, lots of hardlinks ("dirvish" backup trees of my workstations at home.) The disk is currently attached to a very old machine that serves as home server/router, so only 128M RAM and very slow CPU (350MHz PentiumII.) And only USB 1, no less, which I didn''t realize when I bought the disk :-) Since dirvish only writes new files, I can live with it for now. Software: Debian packages, btrfs-tools 0.19 and kernel 2.6.31-rc1 (soon to be rc3) btrfs-convert (using my desktop, which is more or less ok performance-wise, not the old machine): still took ca. 10h. * some progress indication would be nice (needn''t be very accurate, but it would be nice if it could tell me if I''m about to wait another hour or another day...) * documentation: what happens when I kill btrfs-convert? Will I have an ext3 with only free space having been written to, or will I have an unfinished btrfs that I need to rollback with btrfs-convert? Documentation would be nice. (I haven''t tried what happens.) Ok, now I have a btrfs, attached it to the old router. I''m now collecting data if the slow CPU or the slow USB is worse by enabling/disabling -o compress on the mount (will metadata be compressed as well?) Since it basically worked: now tried to delete the image file in the ext2_saved subvolume, which exposed very unexpected behaviour: it takes ages (ok, we''re still on USB1 and the file is huge, after all) and then it kicks the oom killer into action; the system then becomes unusable. Plenty of swapspace free, so I guess "rm" uses quite a bit kernel memory. The backtraces I''ve seen all are just about tasks the OOM killer got rid of, nothing into the btrfs code. On a faster machine with more memory and USB2, removing the image file worked, but I was still surprised at how long it took. Quite some time was spent with vmstat reporting only 1-4M/s reads (dd manages ~20M/s to that disk, full USB2); I can''t tell if it was seeking wildly or if it was CPU (sorry, didn''t think to watch.) After, it seems the free space isn''t tracked properly, the removed image file should have freed up lots of space but no increase in free space is reported by df. Ok, after all those crashes, I''ll now run btrfsck just to be safe. (I haven''t so far, given that it''ll take ages...) Again, progress indication would be nice. And: I notice that btrfsck /dev/sda1 doesn''t complain even if the device is currently mounted. Is online fsck already implemented? Or will fsck run just in readonly mode? A warning would be appropriate. Ok, enough complaints. I''m amazed at what you guys are doing, and await eagerly the moment where I can switch my compuers to btrfs fully (ENOSPC handling and the ability to remove snapshots/subvolumes are the critical bits for me, and of course it shouldn''t eat data. Then creating snapshots before "aptitude upgrade" orgies will make trying out new stuff so much more fun! Btw, will it be possible to designate a new snapshot the "default" snapshot and remove the old default? Not critical, though.) cheers -- vbi -- In short: just say NO TO DRUGS, and maybe you won''t end up like the Hurd people. -- Linus Torvalds, 2001
On Fri, Jul 24, 2009 at 12:37:13PM +0200, Adrian von Bidder wrote:> Heyho! > > Just a first impression report from a pure user. I''ve started to play > around with btrfs a bit, without using any btrfs-specific features so far, > though.Hi, thanks for sending this along.> > 700G, ca. 1/2 full, tons of small files, lots of hardlinks ("dirvish" backup > trees of my workstations at home.) > > The disk is currently attached to a very old machine that serves as home > server/router, so only 128M RAM and very slow CPU (350MHz PentiumII.) And > only USB 1, no less, which I didn''t realize when I bought the disk :-) > Since dirvish only writes new files, I can live with it for now. > > Software: Debian packages, btrfs-tools 0.19 and kernel 2.6.31-rc1 (soon to > be rc3) > > btrfs-convert (using my desktop, which is more or less ok performance-wise, > not the old machine): still took ca. 10h.The btrfs-convert speeds are mostly limited by the speed that you can read the ext3 metadata and data. If you do the conversion without doing csums, it is faster because it doesn''t have to read the ext3 data.> * some progress indication would be nice (needn''t be very accurate, but it > would be nice if it could tell me if I''m about to wait another hour or > another day...)Definitely.> * documentation: what happens when I kill btrfs-convert? Will I have an > ext3 with only free space having been written to, or will I have an > unfinished btrfs that I need to rollback with btrfs-convert? Documentation > would be nice. (I haven''t tried what happens.)You''ll have one or the other, but not something halfway between.> > Ok, now I have a btrfs, attached it to the old router. > > I''m now collecting data if the slow CPU or the slow USB is worse by > enabling/disabling -o compress on the mount (will metadata be compressed as > well?)Only data is compressed.> > Since it basically worked: now tried to delete the image file in the > ext2_saved subvolume, which exposed very unexpected behaviour: it takes > ages (ok, we''re still on USB1 and the file is huge, after all) and then it > kicks the oom killer into action; the system then becomes unusable. Plenty > of swapspace free, so I guess "rm" uses quite a bit kernel memory. The > backtraces I''ve seen all are just about tasks the OOM killer got rid of, > nothing into the btrfs code.Ouch, I haven''t seen this but I''ll try to reproduce it.> > On a faster machine with more memory and USB2, removing the image file > worked, but I was still surprised at how long it took. Quite some time was > spent with vmstat reporting only 1-4M/s reads (dd manages ~20M/s to that > disk, full USB2); I can''t tell if it was seeking wildly or if it was CPU > (sorry, didn''t think to watch.) > > After, it seems the free space isn''t tracked properly, the removed image > file should have freed up lots of space but no increase in free space is > reported by df.The free space won''t show up immediately, it takes a full commit before you''ll see it (run sync). The conversion reuses all of the ext3 data blocks, so the only free space you get back is the ext3 metadata.> > Ok, after all those crashes, I''ll now run btrfsck just to be safe. (I > haven''t so far, given that it''ll take ages...) > > Again, progress indication would be nice. > > And: I notice that btrfsck /dev/sda1 doesn''t complain even if the device is > currently mounted. Is online fsck already implemented? Or will fsck run > just in readonly mode? A warning would be appropriate.Yes, we do need a warning ;)> > Ok, enough complaints. I''m amazed at what you guys are doing, and await > eagerly the moment where I can switch my compuers to btrfs fully (ENOSPC > handling and the ability to remove snapshots/subvolumes are the critical > bits for me, and of course it shouldn''t eat data. Then creating snapshots > before "aptitude upgrade" orgies will make trying out new stuff so much > more fun!Thanks for trying things out and writing up your experience.> Btw, will it be possible to designate a new snapshot > the "default" snapshot and remove the old default? Not critical, though.)Yes. -chris -- 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
2009/7/28 Chris Mason <chris.mason@oracle.com>:> On Fri, Jul 24, 2009 at 12:37:13PM +0200, Adrian von Bidder wrote: >> Heyho! >> >> Just a first impression report from a pure user. I''ve started to play >> around with btrfs a bit, without using any btrfs-specific features so far, >> though. > > Hi, thanks for sending this along. > >> >> 700G, ca. 1/2 full, tons of small files, lots of hardlinks ("dirvish" backup >> trees of my workstations at home.) >> >> The disk is currently attached to a very old machine that serves as home >> server/router, so only 128M RAM and very slow CPU (350MHz PentiumII.) And >> only USB 1, no less, which I didn''t realize when I bought the disk :-) >> Since dirvish only writes new files, I can live with it for now. >> >> Software: Debian packages, btrfs-tools 0.19 and kernel 2.6.31-rc1 (soon to >> be rc3) >> >> btrfs-convert (using my desktop, which is more or less ok performance-wise, >> not the old machine): still took ca. 10h. > > The btrfs-convert speeds are mostly limited by the speed that you can > read the ext3 metadata and data. If you do the conversion without doing > csums, it is faster because it doesn''t have to read the ext3 data. > >> * some progress indication would be nice (needn''t be very accurate, but it >> would be nice if it could tell me if I''m about to wait another hour or >> another day...) > > Definitely. > >> * documentation: what happens when I kill btrfs-convert? Will I have an >> ext3 with only free space having been written to, or will I have an >> unfinished btrfs that I need to rollback with btrfs-convert? Documentation >> would be nice. (I haven''t tried what happens.) > > You''ll have one or the other, but not something halfway between. >> >> Ok, now I have a btrfs, attached it to the old router. >> >> I''m now collecting data if the slow CPU or the slow USB is worse by >> enabling/disabling -o compress on the mount (will metadata be compressed as >> well?) > > Only data is compressed. > >> >> Since it basically worked: now tried to delete the image file in the >> ext2_saved subvolume, which exposed very unexpected behaviour: it takes >> ages (ok, we''re still on USB1 and the file is huge, after all) and then it >> kicks the oom killer into action; the system then becomes unusable. Plenty >> of swapspace free, so I guess "rm" uses quite a bit kernel memory. The >> backtraces I''ve seen all are just about tasks the OOM killer got rid of, >> nothing into the btrfs code. > > Ouch, I haven''t seen this but I''ll try to reproduce it. >This isn''t surprising me. Deleting the image involves almost all used extents in the filesystem. It can create large number of delayed refs. Besides, btrfs_delete_inode does its work in single transaction. Yan, Zheng -- 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