Ebből egyetlen apróságot szerintem rosszul tudsz. A partíciókezelés nem annyira tartozik ide. Egyetlen érdemi része van:
azt ne tedd meg, hogy fizikai diszkeket partícionálsz, és *ugyanarról* a diszkről több partíciót odaadsz ZFS használatára. Általában az a mondás, hogy veszel egy diszket, arra raksz a géptől függően MBR vagy GPT-tipusú partíciós táblát, létrehozol rajta *egyetlen*, az összes szabad helyet lefedő partíciót, ennek a használattól függő típust állítasz be (gondolom emlékszel: klasszikus Linux-FS 0x81, swap 0x82, LVM: 0x8e, MD-device 0xfd , és í. t. - ezek itt az MBR-es értékek, és megvan a megfelelőjük GPT esetén is.) - és aztán ezt a partíciót használod. Ezt a bootoláshoz szükséges diszken kb. így kell használni, az "adat" diszkeken kb. mindegy. Van az az iskola amelyik még a partíciós tábla elfoglalt helyét is meg akarja spórolni, és a másik, amelyik hagyománytiszteletből, "kompatibilitásból", "ennyit nekem ér, hogy ránézésre lehessen tudni hogy ott mi van" okokból minden diszket partícionál - persze egy db. partícióra.
Ez persze a fizikailag egy egységnek látszó diszk particionálása, az LVM-mel létrehozott virtuális diszk (a VG, kötetcsoport) "partticionálása" valóban az LVM feladata - ezért csinálunk LV-ket (logikai köteteket).
Én is olvastam anno arról, hogy HW-RAID-et ne tegyünk ZFS alá, azért halkan megkérdezem, hogy akkor mégis hol a bánatos lóf*ban van a ZFS célterülete, hisz egy kicsit is komolyabb storage környezetben használt SAN eszköz úgy intéz neked RAID-et, hogy rosszabb esetben nem is tudsz róla, hogy a háttérben stripe-oll diszkterületek sokaságából összerakott RAID6 kötet van, és te azt kapod meg egy db LUN-ként. (Jobb esetben a RAID6-ról tudsz, mert ez a megállapodás része a sysadm és a SANadm között.) És máris a kezedben van közvetlen eléréssel az "egész lemez".
Szigorúan elméleti alapon, semmi akadálya - és persze semmi értelme - nincs annak, hogy sok-sok, SANról (multipath-szal :-) ) kiajánlott LUNt, mdadm-mel sok md-eszközzé összefogjak, pár ilyen mdX-et alátoljak egy-egy LVM kötetcsoportnak (*), ezeken a VG-ken sok LV-t csináljak, a létrehozott logikai köteteket ZSF-poolokba szervezzem, ezen poolokban ZVOL-okat hozzak létre, és ezen ZVOL-okra BTRFS fájlrendszert rakjak (**). És kivétel nélkül mindegyik szinten bekapcsoljak ilyen-olyan RAID-szinteket a lineáristól a strie-on és mirroron keresztül a RAID53-ig. Értelemszerűen a világ összes diszkje kevés hozzá, teljesítményben sem valószínű hogy bajnok lesz, de ha *jól* konfigurálod, akkor rohadt sok diszkhez / diszkkontrollerhez kötődő hardverhibát ki tud védeni. Értelme persze nincs, de perverzió kiélésének egyik legkevésbé fájdalmas módja. Viszont menni fog (mert mennie kell). Ha ez valahol megakad, az vagy az adott diszkkezelő hibája (inkább hiányossága), vagy a használt terjesztés összeállítóinak korlátoltsága.
Ha higgadtan végiggondolod, a nem-egygépes-két diszkfiókos, hanem komolyabb környezetben fentiekból általában kettő ilyet összekombinálva használnak - egyszer van valami "hardveres RAID", utána valami "szoftveres RAID" - ahol az előző a SAN, vagy a lokális HWRAID-vezérlő, utóbbi meg az md, a ZFS vagy BTRFS (vagy más, ami nem jutott most eszembe).
(*) Esetleg lehetne még az mdX-eket partícionálni - és ezekből a partíciókból csinálni az LVM VG-ket.
(**) ha a BTRFS a storage pooljából tud blokk-eszköznek látszó tárgyat kiajánlani (a'la ZFS-ZVOL), akkor csinálj ilyen BTRFS_BD alapú blokkos eszközt (ha pedig nem tud, akkor legyen a BTRFS-volume-on losetuppal létrehozott loopY-device) és erre rakjál XFS-t.
Ui: ha lesz hozzá türelmem, akkor megcsinálom otthon. Minden adott hozzá, az egyik FreeBSD-s gép lesz ctld-vel a SAN (jó, szegény ember vízzel főz, nem FC, hanem ISCSI), és a netbookon egy VM-ben már meg lehet csinálni a többit. Az igazi perverzió persze az lenne, ha ez *mind* a netbookon belül lenne létrehozva (1 VM a SAN, egy másik a Linux).
/AGYBAJ