I've been using btrfs for about two years on multiple devices.

I am planning to test some btrfs configurations on a HDD (Single platter) which has non reliable sectors. A dozen of sectors on the HDD are sometimes not readable.

Would there be any difference in terms of data integrity and overall read and write speed in these setups:

-1 TB btrfs partition created with `mkfs.btrfs -d dup -m dup /dev/sda1`

-500 GB partition
-500 GB partition
--500 GB btrfs Raid 1 `mkfs.btrfs -m raid1 -d raid1 /dev/sda1 /dev/sda2`

I would suggest using the variant with dup instead of putting multiple partions on the same device and raiding those. The raid variant is bad because the raid requests both copies to be read while data is accessed (this is good for normal multi-device raid because if either device is faster the data is available sooner). With single device rotational device this causes read head to skip between different partitions so if you have multiple requests in the queue (the usual case) you end up with really bad performance. Increasing queue depth and CFQ scheduler can reduce overall latency a bit but it's better to avoid that mess.

The dup variant should be sane enough to read only one copy usually and only fallback to another copy if sector is not readable.

I'm not sure about dup implementation but I would guess that dup does not put the copy 1/2 device away from the first copy so dup probably increases the write performance, too. With single device raid the write performance will be bad, too, because one logical write operation needs to be written in two locations on physical rotational device and the difference is always 1/2 device so you end up with an algorithm that practically implements the overall worst case behavior for a rotational device.

  • This is incorrect. BTRFS RAID1 only reads the other copy on read if the first copy is corrupted (the same goes for MDRAID). DUP also do place the two copies far apart to increase the chance of recovery. If the duplicated data is on the same sector and that sector is marked as bad you would have a lesser chance of recovery – Waxhead Jun 2 '18 at 10:00
  • If I've understood correctly, mdraid implementation will read both "raid devices" (in this case partitions on the same HDD) if multiple files are accessed in parallel. I didn't know that BTRFS's internal raid implementation was smart enough to avoid hitting HDD device in parallel. How about if LVM is used in addition? In any case, dup is allowed to place copies near by (not on the same sector) but manual partitioning forces copies to stay 50% offset. This causes extra head movement in case of HDD. – Mikko Rantalainen Jun 4 '18 at 6:36
  • Note to self: according to superuser.com/questions/1169537/… Linux mdraid implementation is not able to increase bandwidth of reading a single file, but only the case where multiple separate files are being read in parallel. – Mikko Rantalainen Jun 4 '18 at 6:38
  • 1
    Raid1 allows for uncompressed data on one partition and a compressed copy on the other partition. That might defeat solid state drives internal de-duplication mechanisms (storing duplicate data only once to increase speed). – Pro Backup Dec 29 '18 at 22:03
  • 1
    It seems that BTRFS raid1 isn't able to -o force-compress on only one device/partition of the raid1 set. – Pro Backup Dec 30 '18 at 10:03

Late to the party, but anyway. I was wondering about the same question and in the man I read (about dup):

"For example, a SSD drive can remap the blocks internally to a single copy thus deduplicating them. This negates the purpose of increased redunancy (sic) and just wastes space"

Perhaps raid1 would be a way to avoid that concern (or not).

  • The SSD drive does not know about such concepts as "file system", "partition" or "file". It will happily deduplicate anything that looks like another part of the device. So duplicate sectors may be deduplicated by SSD firmware. If you use full disk encryption with CTR mode, then SSD will not see duplicated sectors. – Mikko Rantalainen Jan 1 at 21:33

In regards to the SSD remapping blocks. The SSD internally does not recognize the partitions, it treats any sector the same. So having the same file (data) as two copies on the same partition is the same result as having two copies on separate partitions. Not all SSD manufactures code the internal storage the same; some may perform block deduplication and others don't.

For an SSD drive: Theoretical data integrity would be the same, any sector has a chance of failure, but the duplicate data/metadata provides redundancy. Read/write performance also the same. SSD does not have a seek or read time difference across the drive.

For an rotating drive: Theoretical data integrity would be the same, any sector has a chance of failure, but the duplicate data/metadata provides redundancy. Read/write performance also the same. Read performance I cannot speak to, as testing would need to be performed. Read can be done from either file copy (in dup) or either partition. However, I do not know if BTRFS is able to optimize this; ie use the copy/partition which is faster at the front of the platter(faster). Write performance would be degraded more with two partitions, as both copies must be written for the IO to be completed. The partition in the second half of the platter will always be slower to seek/read/write.

Note: While RAID mirror is being used, since it is on a single physical device, any device failure means complete data loss. This mirror only protects against sector failures.

  • Note that sector failures are exceedingly rare with SSD devices. With SSD, you usually have perfectly fine working drive until one day you have nothing. Hence the need for real backups. – Mikko Rantalainen Jan 1 at 21:36

I've found at least one difference:

You can mount your degraded raid1 rw only once. The failing chance of a partition while other partition of your device is healthy may be slim, nevertheless this is a difference.

Source: https://btrfs.wiki.kernel.org/index.php/Gotchas#raid1_volumes_only_mountable_once_RW_if_degraded

raid1 volumes only mountable once RW if degraded

Even if there are no single profile chunks, raid1 volumes if they become degraded may only be mounted read-write once with the options -o degraded,rw.


  • This does not happen (reportedly) when there are more than 2 devices.

  • This does not happen with raid10 profile volumes.

  • This is often due to the "Incomplete chunk conversion" issue, where there are single chunks left.

Possible recoveries:

  • If it is still read-write, you can convert the chunks from profile raid1 to profile single (or profile dup) if you have enough space).

  • If it is still read-write, you can btrfs device replace the missing device.

  • When a raid1 volume is stuck as read-only for either reason it can only be recovered by dumping its contents, recreating it and restoring the contents.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.