[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#863290: src:linux: no warning that btrfs RAID5/6 is buggered up




RAID1 actually needs a warning too. It will not work as "classic" RAID1 e.g.
it need to be able to make two copies always to not get stuck in read only mode.
You will not loose your data which is a good thing, but to be safe you need a
minimum of 3 devices (I would prefer four or more to be on the safe side).
Do you mean that btrfs raid1 profile (assume raid1 profile for both
data and metadata) is 2 copies on n devices?  Adding more devices to
the volume does not increase copies or reduce risk; it increases the
size of the volume, but there are still only 2 copies on two different
devices.   As things stand, n-way raid1 profile will not be worked on
until work on raid5/6 profile is in a good state, so many, many years
out.
Ok, I was a bit unclear about this. Let met try to explain.
In RAID1 if you loose one disk for example normal RAID1 remains operational.
BTRFS on the other hand can easily get stuck in read only mode forever.
(explained in detail here : https://www.spinics.net/lists/linux-btrfs/msg63370.html )

So what I mean is that if you only have two devices and loose one you may end
up with a unwriteable filesystem which is not what people expect.
If you have three devices BTRFS RAID1 will continue to work since it can still place
a copy on another drive (thus not creating single chunks).

Now to make matters a tad worse, if you have a drive disappear and reappear due to a controller reset or something other nasty BTRFS does not keep track of the device ID that it use. For example /dev/sdx = id 1, /dev/sdy= id 2 , /dev/sdz = id 3. Now let's pretende that /dev/sdy disappears and reappears as /dev/sdd then idealy BTRFS would know that /dev/sdd now have ID 2. However BTRFS will happily still try to write
to /dev/sdy even if the device ID reappeared as another device.

So that is why I say that three or more devices will reduce the risk of ending up
in a read only mode.

I hope this was a tad cleared.

I've updated the TODO items at https://wiki.debian.org/Btrfs to
explain this in more depth and will write the new sections when I have
a long enough chunk of free time to streamline the article for
Stretch's release.  If there is anything anyone feels should be on our
btrfs wiki page, please let me know so that I can add it to the queue,
or alternatively add it directly to the TODO items.  Also, if there is
anything in that article that seems like it should be moved to the
upstream wiki I would be happy to do that.
For the Debian wiki I think you should include these links:

BTRFS disk usage/utilization calculator
http://carfax.org.uk/btrfs-usage/

I also think the Debian wiki should simply write a few things about
"supported" configurations that BTRFS will run fine under.

If there is anything I can help out with on the BTRFS wiki page,
I would be happy to volunteer to assist with the documentation
a bit in between other things.

Cheers,
Nicholas


Reply to: