On 2015-09-18 00:41, Sean Greenslade wrote:
MD is emulating hardware RAID. In hardware RAID, you are doing work at the block level. Block-level RAID has no understanding of the filesystem(s) running on top of it. Therefore it would have to checksum groups of blocks, and store those checksums on the physical disks somewhere, perhaps by keeping some portion of the drive for itself.
Of course.
But then this is not very efficient, since it is maintaining checksums for data that may be useless (blocks the FS is not currently using).
Correct. But when a disk needs to be swapped you have the same problem - the whole disk needs to be rewritten, because the RAID controller (or software) does not know about the filesystem. TRIM might help in this case.
So then you might make the RAID filesystem aware...and you now have BTRFS RAID.
Right. As long as I don't want to turn off COW.
Simply put, the block level is probably not an appropriate place for checksumming to occur. BTRFS can make checksumming work much more effectively and efficiently by doing it at the filesystem level.
Well, yes and no. The Block level needs checksums to identify silent data corruption - without access to the block layer, the fs can only detect a faulty block, but cannot recover it, even in a raid setting. And without access to the fs, the block layer is inefficient, as you said. So, BTRFS and ZFS are doing the right thing by sacrificing the strict boundary between block and fs layer, imo.
Gert -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
