First impression (pure user)

[Adrian von Bidder <avbidder@fortytwo.ch>]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 388 bytes --]