Re: kernel 3.3.4 damages filesystem (?)

[Daniel Lee <longinus00@gmail.com>]

On 05/07/2012 01:21 PM, Helmut Hullen wrote:
> Hallo, Daniel,
>
> Du meintest am 07.05.12:
>
>>> Yes - I know. But btrfs promises that I can add bigger disks and
>>> delete smaller disks "on the fly". For something like a video
>>> collection which will grow on and on an interesting feature. And
>>> such a (big) collection does need a "gradfather-father-son" backup,
>>> that's no critical data.
>>>
>>> With a file system like ext2/3/4 I can work with several directories
>>> which are mounted together, but (as said before) one broken disk
>>> doesn't disturb the others.
>
>> How can you do that with ext2/3/4? If you mean create several
>> different filesystems and mount them separately then that's very
>> different from your current situation. What you did in this case is
>> comparable to creating a raid0 array out of your disks. I don't see
>> how an ext filesystem is going to work any better if one of the disks
>> drops out than with a btrfs filesystem.
>
>    mkfs.btrfs  -m raid1 -d raid0
>
> with 3 disks gives me a "cluster" which looks like 1 disk/partition/
> directory.
> If one disk fails nothing is usable.

How is that different from putting ext on top of a raid0?

>
> (Yes - I've read Hugo's explanation of "-d single", I'll try this way)
>
> With ext2/3/4 I mount 2 disks/partitions into the first disk. If one
> disk fails the contents of the 2 other disks is still readable,

There is nothing that prevents you from using this strategy with btrfs.

>
>> It sounds like what you're thinking of is creating several separate
>> ext filesystems and then just mounting them separately.
>
> Yes - that's the old way. It's reliable but "ugly".
>
>> There's nothing inherently special about doing this with ext, you can
>> do the same thing with btrfs and it would amount to about the same
>> level of protection (potentially more if you consider [meta]data
>> checksums important but potentially less if you feel that ext is more
>> robust for whatever reason).
>
> No - as just mentionend: there's a big difference when one disk fails.

No there isn't.

>
>> If you want to survive losing a single disk without the (absolute)
>> fear of the whole filesystem breaking you have to have some sort of
>> redundancy either by separating filesystems or using some version of
>> raid other than raid0.
>
> No - since some years I use a kind of outsourced backup. A copy of all
> data is on a bundle of disks somewhere in the neighbourhood. As
> mentionend: the data isn't business critical, it's just "nice to have".
> It's not worth something like raid1 or so (with twice the costs of a non
> raid solution).
>
>> I suppose the volume management of btrfs is
>> sort of confusing at the moment but when btrfs promises you can
>> remove disks "on the fly" it doesn't mean you can just unplug disks
>> from a raid0 without telling btrfs to put that data elsewhere first.
>
> No - it's not confusing. It only needs a kind of recipe and much time:
>
>          btrfs device add ...
>          btrfs filesystem balance ... (perhaps no necessary)
>          btrfs device delete ...
>          btrfs filesystem balance ... (perhaps not necessary)
>
> No intellectual challenge.
> And completely different to "hot pluggable".

This is no different to any raid0 or spanning disk setup that allows 
growing/shrinking of the array.