2009/7/28 Chris Mason <[email protected]>: > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
