0

I have an existing btrfs filesystems on a 2TB disk and I want to add another 5TB disk as redundancy.

I can simply format the new disk with btrfs and add the device with 

btrfs device add /dev/sdX /mymountpoint
btrfs filesystem balance start -dconvert=raid1 -mconvert=raid1 /mymountpoint

I’ll end up with 2TB usable disk space and everything on both disks. However, I could have more redundancy if I could use the spare 3TB on my 5TB disk such that every write goes twice to the larger disk (2TB disk store everything once, 5TB stores everything twice). Is this possible?

I am aware of the disadvantages such as higher latency, reduced speed etc.

Improve this question

2 Answers 2

Reset to default
2

Technically if you create two partitions of 2 TB each on the larger disk, you will be able to use them along with the smaller disk (or its partition) as three devices of equal (or almost equal) size.

Even if you're OK with disadvantages, don't do it. This is the reason:

btrfs combines all the devices into a storage pool first, and then duplicates the chunks as file data is created. RAID-1 is defined currently as "2 copies of all the data on different devices". This differs from MD-RAID and dmraid, in that those make exactly n copies for n devices. In a btrfs RAID-1 on three 1 TB devices we get 1.5 TB of usable data. Because each block is only copied to 2 devices, writing a given block only requires exactly 2 devices to be written to; reading can be made from only one.

(source)

So it may (and will) happen that some data end up on the two partitions of the larger disk but not on the smaller one. I guess such "poor man's redundancy" sometimes may help if the larger disk fails partially/locally. If it fails as a whole then the data that happens to be stored on it twice will be lost.

What you want can be done with the "n copies for n devices" approach (again: two partitions on the larger disk are devices in this context). You may be interested in RAIDing with LVM vs MDRAID - pros and cons.

If I were you I wouldn't do this though. In this setup each write operation engages the two partitions on the same physical device. Even if you write sequentially to both partitions, these are concurrent writes that require the heads to move back and forth; unless you specifically manage to set the partitions up, so corresponding writes are performed by two different heads in the same position of the common arm. Is the firmware able to write using two heads at the same time? Will data always arrive for both partitions semi-simultaneously in the first place? Won't any read operation be scheduled between the corresponding writes to the two partitions? I doubt all of these.

So it's reasonable to assume the heads will travel more than in a non-RAID configuration. This will probably reduce the lifespan of the arm. When it mechanically fails, the whole disk fails. Then it doesn't matter how many copies you had on it; what is left is the smaller disk only.

Conclusion: it may be that your idea increases the risk of failure of the type that (when it occurs) makes the additional redundancy completely irrelevant.

Improve this answer
1
  • Thanks for your feedback. I had the idea of using partitions on the larger disk as you suggested but concluded as you did that this will add more risk than benefit. I hoped btrfs supports something like device specific configurations for redundancy of data and metadata. Seems as if this is not the case.
    – user3422070
    Jul 1, 2019 at 5:54
0

There's no straightforward way of implementing this with btrfs. More importantly, though, it's a dangerous configuration which should not be used.

The purpose of RAID1 is redundancy. Storing data twice on a single disk doesn't provide redundancy: if that disk fails, your data is lost.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .