Btrfs RAID: Built-In/Native RAID vs. Mdadm

[liam]

Does Btrfs have data recovery capabilites when using only one disk? For example, use an error correction code at the expense of disk space and performance?

I was confused when data integrity checking and recovery occurred. From the comments, it sounds like it's either done manually through a command (default) or on every read (for debugging only).

Not to my knowledge. Keep in mind that the disks themselves can recover corrupted blocks (using r-s, I believe) up to n flips. The exact value of n relies on the length of the stored value.
Unfortunately btrfs has a frozen disk structure so I'm not sure they can make the changes necessary to add such a feature.

[guido12]

Not to my knowledge. Keep in mind that the disks themselves can recover corrupted blocks (using r-s, I believe) up to n flips. The exact value of n relies on the length of the stored value.
Unfortunately btrfs has a frozen disk structure so I'm not sure they can make the changes necessary to add such a feature.

Thanks. I guess I'm okay with restoring files from a backup when the scrub utility tells me that a file is corrupt.

[liam]

Thanks. I guess I'm okay with restoring files from a backup when the scrub utility tells me that a file is corrupt.

To be clear, you should be able to recovery older versions of the days by looking at the file with most recent gens number and a consistent checksum.
For backups btrfs has the send/receive utility. I'm not certain how stable it is right now but it's definitely worth a look.

[m_o_d]

mdadm raid10 and layout

Hi,
At the beginning I wanted to thank for taking the time tested.
Reading the comparison of disk I noticed that you are using the default layout for raid10. Whether in future tests can be considered a test for raid 10 with layout set to f2?

mdadm ... -p f2

"f" - means 'far' copies (multiple copies have very different offsets)
"2" - means number of copies

for two disks:
* read like stripe
* write like mirror
* security like mirror

[ssam]

Those checking features aren't the default. They are mount options called check_int and check_into_data (iirc), and are considered only useful for debugging b/c they cause massive slow downs (their words).

The wiki has been updated to be more clear.

"check_int (since 3.3)
Switch on integrity checker for metadata (if compiled in). This is not the same as checksum verification, which is always done. Note: this is a debugging-only option, and will slow down your filesystem massively. " https://btrfs.wiki.kernel.org/index.php/Mount_options

From discussion on btrfs IRC, the default settings are:
"With RAID-1, it'll try reading one copy. That copy is checked. If it's broken, then the other copy is read and checked. If the second copy is good, the good data is returned and the first copy is fixed. The the second copy is also bad, the FS returns EIO."

This is an advantage over traditional RAID, where you have to scrub to discover the error, and then have no way to know which copy is valid.

[ByteTraveller]

Damn, you beat me to it - I've just finished a small project to prove btrfs detects corruption on any read, due to reading the previous posts stating it doesn't.

If you want to try yourself, follow these instructions to corrupt a file outside of btrfs, after reading the file, check the syslog. WARNING: prior to kernel v3.20 corruption detection events are stupidly logged under the INFO severity, so monitoring scripts will probably miss them.

[tom94022]

I suspect the benchmark results are strongly influenced by the use of software RAID and small block sizes.

• Software RAID introduces parity block calculation for all RAIDs except 0, 1 and 10 which introduces CPU and software efficiency delays.
• RAID other than RAID 1 should read/write faster than a single drive if the host supports parallelism the fastest being a function of the parallelism. Using 16 KiB blocks makes the read or write times a very small percentage of the total access time so it is not surprising that the results of your benchmarks are confusing as to the efficacy of RAID.
• RAID 1 and 10 have the possiblity of seek overlap improving performance against which there is the requirement of writing twice the data, the performance of which again all can be affected by the software implementation.

Why don't u try a 0.5 GiB block size and see what the results look like (about 1 second per access). That should swamp out every thing else. I'll make a donation just to encourage it

BTW, my suggested problems with the benchmarks doesn't mean that they are not relevant to most real world small system users where the OS doesn't do a good job of blocking the actual files sent to disk, but the primary users of RAID are in the server area and there the optimzation is likely far better. FWIW I will probably use two SSDs as RAID 1 on my next system, looking for the seek overlap on read improvement and the protection of RAID 1 against an SSD failure (IMO not yet as reliable as HDDs).