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
Attachment:
signature.asc
Description: This is a digitally signed message part.
