2009/7/28 Chris Mason <chris.mason@xxxxxxxxxx>:
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
