> On Mar 6, 2017, at 5:56 AM, Pasi Kärkkäinen <pasik@xxxxxx> wrote: > > On Sun, Mar 05, 2017 at 09:15:39AM +0100, Mikael Abrahamsson wrote: >> On Fri, 3 Mar 2017, Gandalf Corvotempesta wrote: >> >>> This is what ZFS does. This is what Gluster does. This is what BRTFS does. >>> Adding this in mdadm could be an interesting feature. >> >> This has been discussed several times. Yes, it would be interesting. >> It's not easy to do because mdadm maps 4k blocks to 4k blocks. Only >> way to "easily" add this I imagine, would be to have an additional >> "checksum" block, so that raid6 would require 3 extra drives instead >> of 2. >> >> The answer historically has been "patches welcome". >> > > There was/is an early prototype implementation of checksums for Linux MD RAID: > > http://pages.cs.wisc.edu/~bpkroth/cs736/md-checksums/ > http://pages.cs.wisc.edu/~bpkroth/cs736/md-checksums/md-checksums-presentation.pdf > http://pages.cs.wisc.edu/~bpkroth/cs736/md-checksums/md-checksums-paper.pdf > http://pages.cs.wisc.edu/~bpkroth/cs736/md-checksums/md-checksums-code.tar.bz2 > > > Also there's the T10 DIF / DIX (Data Integrity Fields / Data Integrity eXtensions) functionality that could be used, at least if the hardware setup is SAS-based (SAS HBA + enterprise SAS disks and modern enough firmware on both that enable DIF/DIX..). > > I guess MD RAID could also 'emulate' T10 DIF/DIX even if the HBA/disks don't support it.. but dunno if that makes any sense. There is a device-mapper target that is designed to do precisely this - dm-integrity (see dm-devel mailing list). It currently being developed as part of an authenticated encryption project, but could be used for this too. Note that there is a performance penalty that comes from emulating this. brassow -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
