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] btrfs



All of this distinction between raid0, mirroring, raid10, in context of btrfs, is irrelevant, because it's true for straight-up traditional RAID, which is not what's happening in btrfs or zfs.

In btrfs and zfs, it goes like this:
mirror dev0 dev1 dev2
or
raid1 dev0 dev1 dev2
This makes a 3-way mirror.  Total usable capacity of a single disk, triple redundant.

dev0 dev1
People will often call this raid0, or striping, which is not techically correct.  It is actually a concatenation, but since the software (btrfs, zfs) has knowledge of the underlying devices, and since the software's raison-d'etre is to transparently remap virtual file blocks to physical blocks using COW, it's able to map sequential virtual blocks from sequential sections of parallel devices.  Which means you get the performance of striping, without the physical constraints of striping.  Two sides of a mirror need to match each other's geometry (because of mirroring) but you can concatenate any number of non-equal size mirrors.  This is unlike true raid-0 striping, in which all raid-0 devices must have the same geometry and you can't incrementally add one more device at a time.

mirror dev0 dev1 mirror dev2 dev3
or
raid1 dev0 dev1 raid1 dev2 dev3
People will often call this a raid10, which is not correct technically, as with the raid0 stripe.  This is in actuality, a concatenation of two mirrors, where the system performs like a raid-10 with the flexibility of a concatenation.




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