Re: [RFE] Please, add optional RAID1 feature (= chunk checksums) to make it more robust

[Jaromir Capik <jcapik@xxxxxxxxxx>]

> On 18 July 2012 12:01, Jaromir Capik <jcapik@xxxxxxxxxx> wrote:
> > Hello.
> >
> > I'd like to ask you to implement the following ...
> >
> > The current RAID1 solution is not robust enough to protect the data
> > against random data corruptions. Such corruptions usually happen
> > when an unreadable sector is found by the drive's electronics
> > and when the drive's trying to reallocate the sector to the spare
> > area.
> > There's no guarantee that the reallocated data will always match
> > the original stored data since the drive sometimes can't read the
> > data
> > correctly even with several retries. That unfortunately completely
> > masks
> > the issue, because the sector can be read by the OS without
> > problems
> > even if it doesn't contain correct data. Would it be possible
> > to implement chunk checksums to avoid such data corruptions?
> > If a corrupted chunk is encountered, it would be taken from the
> > second
> > drive and immediately synced back. This would have a small
> > performance
> > and capacity impact (1 sector per chunk to minimize performance
> > impact
> > caused by unaligned granularity = 0.78% of the capacity with 64k
> > chunks).
> >
> > Please, let me know if you find my request reasonable or not.
> >
> > Thanks in advance.
> >
> > Regards,
> > Jaromir.
> >
> > --
> > Jaromir Capik
> > Red Hat Czech, s.r.o.
> > Software Engineer / BaseOS
> >
> > Email: jcapik@xxxxxxxxxx
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic
> > IC: 27690016
> >
> >
> > --
> > 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
> 
> That would be a disk format change...
> 

Hello Mathias.

Yes. That would be a disk format change ... but optional only!
Chunks would be interleaved with checksums, therefore the small
capacity loss.

> Why not use btrfs or zfs?

I know btrfs implements that, but AFAIK it still lacks the transparent
encryption. Am I wrong?
In that case I would have to create one large regular file holding the
LUKS data and modify the initramdisk to handle that.

I could give ZFS a try ... 

> 
> Mathias
> 

Thanks,
Jaromir.
--
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