Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] On Btrfs raid and odd-count disks



On 4/15/2013 10:48 AM, Derek Atkins wrote:
> Disk write errors are RARELY reported by the disk interface, because the
> write error can happen due to multiple causes, few of which the

It depends on the cause of the write fault. If it's a hardware fault
then you'll get SCSI sense errors and these will be logged. If it's bit
errors then they may go undetected. And if the controller goes haywire
then all bets are off.

> A raw mirror isn't sufficient because you don't know which mirror has
> the "good" data.

The worse case is if both replicas have different bad data.

> I don't know enough about RAID5 and RAID6 to know if there is proper ECC
> within the RAID itself or if you need additional data.

RAID5 is XOR calculations (parity) of the original data spread across
all of the other devices in the set. As such there is error detection
but there is no error correction since there is no way to tell which
bits are good and which are bad. And like the mirror set there is the
worse case of real and parity data both having bad spots.

> ZFS (and possibly BTRFS) seem to have enough metadata to correct small
> errors.

That's what they're designed to do: detect and correct if possible
single-bit errors. Neither are replacements for robust backups.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org