Comment Not remotely for normal end users. (Score 1) 68
AFAICT, this is explicitly for fixing flips in transmission between the disk and the page cache. On the storage medium, data is almost certainly already encoded using Reed-Solomon codes or Hamming codes or something of that nature, so you won't receive a block with embedded errors, you will receive a failure to read the block. And you can get ECC for you rmemory. But there may not be end-to-end ECC for every step of transmission. So instead of imagining an entirely new hardware ecosystem (which will never happen), this just stores the data in an encoding which can be decoded once inside the ECC protection of the CPU and memory subsystem.
Saying it doesn't store redundant data isn't really correct. These codes necessarily inflate the storage size to accommodate redundancy. I don't think it's really comparable to the redundancy of ZFS or RAID, which group blocks together for encoding so that you can split the no-error fast path away from the slow error-recovery path.
All of that said, this seems like it would be cleaner as a device-mapper layer. Like you could have two in-memory pages encode into three on-disk pages, or four map to five, etc. Having it as a new filesystem could allow stronger optimization opportunities because you could have internal structures not cross page boundaries, but also infinite opportunity for errors. You'll still have to solve the problem of the decoded block size not matching the OS page size (Reed Solomon inline is going to eat 20% or 25% of the page's storage space).
Just thinking about having to bounds-check all of your short reads is kind of freaking me out. There are SO many assumptions baked in around having disk operations happen on memory-page-sized chunks.