First impression (pure user)
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
Signature · 3 lines
In short: just say NO TO DRUGS, and maybe you won't end
up like the Hurd people.
-- Linus Torvalds, 2001Quoted 5 lines · Adrian von Bidder
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.
Quoted 9 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
* 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.
Quoted 4 lines
* 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.
Quoted 6 lines
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.
Quoted 8 lines
Since it basically worked: now tried to delete the image file in the
ext2_savedsubvolume, 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.
Quoted 10 lines
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.
Quoted 9 lines
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/sda1doesn'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 ;)
Quoted 7 lines
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.
Quoted 2 lines
Btw, will it be possible to designate a new snapshot
the "default" snapshot and remove the old default? Not critical, though.)
Yes.
-chris
2009/7/28 Chris Mason <[email protected]>:
Quoted 4 lines · Adrian von Bidder
Quoted 3 lines
Heyho!
Just a first impression report from a pure user. =A0I've started to =
play
Quoted 1 line
Quoted 1 line
around with btrfs a bit, without using any btrfs-specific features s=
o far,
Quoted 6 lines
Quoted 1 line
though.
Hi, thanks for sending this along.
Quoted 2 lines
700G, ca. 1/2 full, tons of small files, lots of hardlinks ("dirvish=
" backup
Quoted 3 lines
Quoted 3 lines
trees of my workstations at home.)
The disk is currently attached to a very old machine that serves as =
home
Quoted 1 line
Quoted 1 line
server/router, so only 128M RAM and very slow CPU (350MHz PentiumII.=
) =A0And
Quoted 1 line
Quoted 1 line
only USB 1, no less, which I didn't realize when I bought the disk :=
-)
Quoted 3 lines
Quoted 3 lines
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 (s=
oon to
Quoted 3 lines
Quoted 3 lines
be rc3)
btrfs-convert (using my desktop, which is more or less ok performanc=
e-wise,
Quoted 4 lines
Quoted 1 line
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. =A0If you do the conversion without =
doing
Quoted 3 lines
csums, it is faster because it doesn't have to read the ext3 data.
Quoted 1 line
=A0* some progress indication would be nice (needn't be very accurat=
e, but it
Quoted 1 line
Quoted 1 line
would be nice if it could tell me if I'm about to wait another hour =
or
Quoted 5 lines
Quoted 1 line
another day...)
Definitely.
Quoted 1 line
=A0* documentation: what happens when I kill btrfs-convert? =A0Will =
I have an
Quoted 2 lines
Quoted 2 lines
ext3 with only free space having been written to, or will I have an unfinished btrfs that I need to rollback with btrfs-convert? =A0Docu=
mentation
Quoted 8 lines
Quoted 1 line
would be nice. =A0(I haven't tried what happens.)
You'll have one or the other, but not something halfway between.
Quoted 5 lines
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 compre=
ssed as
Quoted 7 lines
Quoted 1 line
well?)
Only data is compressed.
Quoted 3 lines
Since it basically worked: now tried to delete the image file in the
ext2_savedsubvolume, which exposed very unexpected behaviour: =A0it=
takes
Quoted 1 line
Quoted 1 line
ages (ok, we're still on USB1 and the file is huge, after all) and t=
hen it
Quoted 1 line
Quoted 1 line
kicks the oom killer into action; the system then becomes unusable. =
=A0Plenty
Quoted 1 line
Quoted 1 line
of swapspace free, so I guess "rm" uses quite a bit kernel memory. =A0=
The
Quoted 1 line
Quoted 1 line
backtraces I've seen all are just about tasks the OOM killer got rid=
of,
Quoted 4 lines
Quoted 1 line
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