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

[liam]

For those looking to try out btrfs themselves, there is also the feature benefit of doing btrfs-native raid: transparent correction of bad data. When blocks are read in, checksums are verified. If there are any errors, Btrfs tries to read from an alternate copy and will repair the broken copy if the alternative copy succeeds.. mdadm doesn't provide that functionality.

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).

[RussDill]

I usually am very quick to say to not use btrfs. Because the only good experience was a desktop experience, and in all other cases btrfs always corrupted itself in such a way that we just had to delete 1...4TB of data and start all over.
But once btrfs is really trustworthy I would run it instead of mdadm.

Its not as if mdadm is perfect either. I've had it destroy a 2TB ext3 filesystem in RAID1 configuration due to a wrap around bug. raid does not and will not ever replace backups.

[ua=42]

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).

Ummm. Source? I don't see any reference to this in the gotcha's page.

[liam]

Ummm. Source? I don't see any reference to this in the gotcha's page.

https://btrfs.wiki.kernel.org/index.php/Mount_options

Says, in bold, that they are for debugging purposes as they will massively slow down the system.
This shouldn't be hugely surprising as that's why we have scrub. I'd imagine that zfs also does the same thing (relies on periodic scrubs rather than a per read integrity check).
I'm not sure why it would slow things down, though, as long as the checksum is near the data extents. Perhaps it's because it forces, effectively, direct io of the entire file rather than mmap and lazy reads? Certainly the checksum should be extremely fast for most computers.

[pascal_dher]

Integrity check option is not the same as checksumming

https://btrfs.wiki.kernel.org/index.php/Mount_options

Says, in bold, that they are for debugging purposes as they will massively slow down the system.
This shouldn't be hugely surprising as that's why we have scrub. I'd imagine that zfs also does the same thing (relies on periodic scrubs rather than a per read integrity check).
I'm not sure why it would slow things down, though, as long as the checksum is near the data extents. Perhaps it's because it forces, effectively, direct io of the entire file rather than mmap and lazy reads? Certainly the checksum should be extremely fast for most computers.

The integrity check is not the same as the checksumming.
The option that turns checksumming off is called nodatasum(documented on the same page) - it says turning it off doesn't result in any considerable performance gains on a modern CPU.

[ua=42]

Correct me if I'm wrong.

I thought with mirror 1, when btrfs read a file. It would check the file against the checksum to see if there had been bitrot and fix the file if there was any.

[benmoran]

The integrity check is not the same as the checksumming.
The option that turns checksumming off is called nodatasum(documented on the same page) - it says turning it off doesn't result in any considerable performance gains on a modern CPU.

Exactly right, it would be pretty stupid if checksumming wasn't enabled by default. It's half the point of the fs!

Word on the street is that turning off checksumming via nodatasum has pretty impressive speedups.

[liam]

The integrity check is not the same as the checksumming.
The option that turns checksumming off is called nodatasum(documented on the same page) - it says turning it off doesn't result in any considerable performance gains on a modern CPU.

I didn't say they are the same. Nodatasum just turns off checksum creation for new files. It doesn't say anything about verifying the checksum of the file on each read. It's the verification step that appears to be the one that can slow the system down.
If you have a reference that says otherwise I'd be happy to read it.

[liam]

Exactly right, it would be pretty stupid if checksumming wasn't enabled by default. It's half the point of the fs!

Word on the street is that turning off checksumming via nodatasum has pretty impressive speedups.

Checksum is turned on by default. Verifying the checksum on every read isn't, however.
Again, that's why theres the scrub utility.

[guido12]

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).