ZFS resilver

Még 2017 végén blogoltam itt a Microserveremről. Most döglött meg az első diszk 60 ezer óra után, ami majdnem 7 év! Előre lelövöm a poént, ez egy #worksforme poszt lesz.

Egyszerű felállás: Microserver Gen10, Debian, 4 db WD30EFRX (3 TB red, még a plus/pro szétválás előtti széria) raidz2-ben plusz egy Intel DC SSD rendszernek. Hogy teljes legyen az élmény, fent van még a zfs-auto-snapshot és a zfs-zed csomag is. Valamelyik csomag a crontabba tett egy havi scrubot is. Imádom a ZFS-t, hogy ennyire egyben van minden.

Hétfő reggel várt az email a zedtől, hogy az egyik diszk meghalt.

  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 0h1m with 0 errors on Sun Jul 13 00:25:05 2025
config:

	NAME                                    STATE     READ WRITE CKSUM
	rpool                                   ONLINE       0     0     0
	  2940b0c2-5a31-419d-af5b-1384b63fc84f  ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: DEGRADED
status: One or more devices has been removed by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using 'zpool online' or replace the device with
	'zpool replace'.
  scan: scrub repaired 0B in 5h35m with 0 errors on Sun Jul 13 05:59:59 2025
config:

	NAME                                      STATE     READ WRITE CKSUM
	tank                                      DEGRADED     0     0     0
	  raidz2-0                                DEGRADED     0     0     0
	    d178ed3e-0112-41fb-8fb9-8da9fed4f30c  ONLINE       0     0     0
	    c6169e04-a51e-48c9-b6ba-9ee3622e57d8  REMOVED      0     0     0
	    9b9d6f83-cb7b-4f82-94ec-d69de9e981f0  ONLINE       0     0     0
	    366946fa-817c-446c-b81b-a44af45ce896  ONLINE       0     0     0
	logs
	  a735c189-9204-4eb5-88fb-5bc08d405732    ONLINE       0     0     0

errors: No known data errors

Dmesgből nem sok minden derült ki, ilyenek voltak többször egymás után:

[10703412.217927] sd 1:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[10703412.217931] sd 1:0:0:0: [sdb] tag#18 CDB: Write(16) 8a 00 00 00 00 00 00 00 0b 10 00 00 00 08 00 00
[10703412.217934] print_req_error: I/O error, dev sdb, sector 2832
[10703412.217975] sd 1:0:0:0: [sdb] Read Capacity(16) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[10703412.217978] sd 1:0:0:0: [sdb] Sense not available.
[10703412.218000] sd 1:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[10703412.218003] sd 1:0:0:0: [sdb] Sense not available.
[10703412.218011] sd 1:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[10703412.218016] sd 1:0:0:0: [sdb] tag#19 CDB: Write(16) 8a 00 00 00 00 01 5d 4d dd 10 00 00 00 08 00 00
[10703412.218019] print_req_error: I/O error, dev sdb, sector 5860351248

Nyilván az első gondolatom a pánik volt, meg már azt is elfelejtettem, hogy raktam ezt össze annak idején, de aztán arra jutottam, hogy 1) a ZFS nagyon fasza, és biztos jól raktam össze régen, nem lesz gond 2) majd újra beletanulok, és most már Gemini is segít nekem 3) nagyon kritikus adat úgysincs rajta.

Kérdés, hogy hogyan javítható a helyzet. Kontakthiba nem valószínű. Smart-ra nem reagál. Aztán a többi diszk smartjából derült ki, hogy 60643 óránál járunk. Na, ez egy nagyon szép kor volt, még kikapcs-bekapcs módszerrel sem fogok próbálkozni, ez csere.

Rendeltem egy WD40EFPX-et (4 TB red plus). Érdekesség, hogy a régi diszk 100 CHF volt, ez meg 99 CHF. Nesze neked infláció! Még hétfőn este megjött. Kedden be is szereltem.

Már ott vakartam a fejem, hogy mi lehet az az UUID azonosító, a /dev/disk/by-partuuid/ alól került elő a válasz. Megdicsértem régi önmagam, hogy partíciót használtam teljes diszk helyett. Aztán parted segítségével pár perc alatt csináltam egy, a többivel megegyező partíciót, és a lényeg a következő parancs volt:

zpool replace tank /dev/disk/by-partuuid/c6169e04-a51e-48c9-b6ba-9ee3622e57d8 /dev/disk/by-partuuid/2842ae6e-f642-4a24-b2a5-ca8f24d49d26

Várakozás, majd minden újra online, ezzel az összegzéssel:

  scan: resilvered 1.48T in 5h18m with 0 errors on Tue Aug  5 16:44:06 2025

Szóval most minden fasza, teljesen eseménymentes volt az egész, ahogy a nagy könyvben meg van írva. Majd szerdán szét is szedem fizikai megsemmisítés céljából a hősi halottunkat (izgatottan várom, úgy sikerült leélni eddigi életemet, hogy még sosem szedtem szét egy diszket sem).

Most azon agyalok, hogy az a 7 év nem vicc, főleg azért, mert az összes diszk egyforma és egyszerre vettem őket, szóval várható, hogy sűrűsödni fognak az események, és nem kellene kísérteni a sorsot.

A másik 3 diszk állítólag jól érzi magát, hasonló számokkal:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       19
  3 Spin_Up_Time            0x0027   180   179   021    Pre-fail  Always       -       5958
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       107
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   017   017   000    Old_age   Always       -       60643
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       105
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       25
193 Load_Cycle_Count        0x0032   121   121   000    Old_age   Always       -       237405
194 Temperature_Celsius     0x0022   118   105   000    Old_age   Always       -       32
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

Valószínűleg majd fogom azt, amelyiknél a legnagyobb az első attribútum (0, 14 és 19 van), és szegényke kap egy preemptív eutanáziát. Utána a maradék 2-nél már mindegy, hogy meddig bírják, a redundancia miatt.

De erre is két lehetőség van. Vagy eljátszom ugyanezt a replace/resilver dolgot, mint ami most volt. Az most így egy bejáratott dolog, de veszélyes, ha akkor kezd el megdögleni pont a többi. A másik, hogy bootolok egy Clonezillát vagy hasonlót, és az egész diszket lemásolom, mert azt feltételezem, hogy ezután úgy tudom elvégezni a cserét, hogy a ZFS mit sem sejt róla (hiszen a partuuid ugyanaz maradna). Ennek egyetlen hátránya lehet, hogy tovább tart, mert foglaltsági infó hiányában egy egész diszket le kell másolni. Viszont a nagy előnye a másik módszerhez képest, hogy a pool egyetlen pillanatra sem kerül degraded állapotba.

Frissítés: állítólag lehet úgy is replace-t indítani, hogy a cserélendő lemezt nem veszem ki előre, és így nem lesz degraded a pool egy pillanatra sem. Mivel több lemez nem fér a szerverbe, és USB-n kell rákötni, de nem lesz teleírva a lemez, ezért a két előző opció között valahol félúton lesz az időigénye, ami nekem teljesen jó. Pár óra múlva jön a második új lemez, majd írok arról is.

( dlaszlo | 2025. 08. 06., sze – 10:17 )

Szerkesztve: 2025. 08. 06., sze – 10:21

2016 júniusában vettem 2 db ugyanilyen 3Tb-os WD red-et, nekem a Power_On_Hours itt tart: 48961. De az egyik diszket 1-2 éven belül cserélni kellett.

Az idejük nagy részében egy Synology DS216j-ben voltak, de már áttettem őket egy Freebsd-s gépbe, és ZFS-sel használom őket.

Gondolkodtam már, hogy nem várom meg, amíg (természetesen) egyszerre:) megadja magát mindkettő 1-2 éven belül, hanem valamikor lecserélem. Én 4 Tb-os NAS-ba való Toshibákat néztem ki.

Van mentésem egy másik ZFS-es gépre, zrepl-et használok.

( ricsip v | 2025. 08. 06., sze – 10:48 )

sub

Pont mostanában tervezek én is egy kis ZFS-t tanulni. Tele van a jutub ZFS tutorial videókkal, de a többség számomra zagyva (az illető nem tud magyarázni azon a szinten amire nekem szükségem volna, vagy egyszerűen csak szar tanár) nehéz megtalálni a nagy zajban azt az 1-2-t, ami tényleg az alapoktól mutatja be a teljes koncepciót.

Mert hát storage-hoz NEM szokott embernek a használt fogalmak elsőre elborzasztónak fognak tűnni, és a ZFS maga is a bonyolultabb szofisztikáltabb filerendszerek közé tartozik. Sok mítosz, sok berögződés keveredik az interneten a 10 évvel ezelőtti vs a valós 2025-ös már megváltozott állapotokkal.

Ez régi de nem rossz, ha szánsz rá egy kis pénzt is. Az alapok nem változtak.

https://devopsakademia.com/course/zfs-sokkal-tobb-mint-fajlrendszer/

https://devopsakademia.com/course/zfs-menedzsment-alapjai/

Ezt meg itt a ZFS fan clubban szedegettük össze:

  1. Mikor használj ZFS-t.

    • A ZFS alapvetően egy szerverekre szánt nagy integritású és megbízhatóságú rendszer, érezhető hardver és tudásigénnyel. Természetesen nincs akadálya, hogy desktop rendszeren használd, az 19.10-es verziótól az Ubuntu telepítője például már támogatja a használatát.

  1. A ZFS nem az n+1-ik fájlrendszer, sokkal több annál, ezért ne is úgy gondolj rá!

    • A ZFS három kulcsfontosságú tárolási réteget (RAID, logikai kötetkezelés és fájlrendszer) egyetlen entitásba csomagol, ezért nem lehet egyszerű fájlrendszerként tekinteni rá. Ennek számos előnye van, a nagyobb integritástól, az egyszerűbb kezelésig. Sajnos egy pár dogot újra kell tanulni miatta, de cserébe itt egy lista, hogy egymaga miket cserél le, ha elkezded használni: hw raid szoftverek, md, lvm, fájlrendszerek (ext3, ext4, xfs, stb.), mkfs, fsck, fstab, dd...

  1. Ne használj semmilyen RAID rendszert a ZFS alatt, különösen hardver RAID-et ne, de szoftver RAID-et sem.

    • A ZFS nem támogatja a hardver RAID használatát. A ZFS egy teljes önálló rendszer a lemezre írástól a RAID és kötetkezelesen át a fájlrendszerig, nincs szükség alá semmilyen egyéb rendszerre, hardver RAID-re meg pláne. Gondolom nem használsz egy szerverben egymás alatt két RAID kontrollert, a ZFS alá se tegyél, használj HBA kontrollert. Az újabb RAID kontrollereket át lehet kapcsolni HBA módra, az természetesen jól használható.

  1. A ZFS gyors működéséhez három dolog kell, RAM, RAM és még több RAM.

    • A leggyakoribb probléma a ZFS-el az elégtelen memória méret. 2 GB elég lehet tesztelésre, vagy a sarokba egy nagyon kis terhelésű NAS-nak de komoly munkára nem elég. 4 GB-val el lehet indulni, de inkább 8 GB-ot számolj minimumnak. Terhelés függően lehet, hogy még ezt is érdemes lesz növelni. Ez persze a többi (rendszer, alkalmazások, stb.) memóriafogyasztás felett számítandó!

  2. A deduplikáció memóriaigénye, nagyon nagy. 4-5GB RAM / 1 TB adatmennyiség (blocks * 320 bytes) A lemez olcsó(bb) lehet, ha nem muszáj ne használd.

    • A deduplikáció memóriaigénye a többi (pl. ARC) memórián felül számolandó, ezen kívül CPU is kell neki. Nem biztos, hogy megéri az extra teljesítmény és memória ráfordítást, ha megoldható helyette több lemezzel, számolj utána.

  3. A LOG (Separate Intent Log SLOG) használata nem biztos, hogy növeli a teljesítményt.

    • Az SLOG (ZIL-nek is szokták nevezni tévesen) lemez használata ez egyik módszer amivel gyorsítani lehet a ZFS írási sebességét. Vagy mégsem, mert csak a sync írást gyorsítja. Járj utána mikor, mire jó és mire nem. Ha nem tudod mi a különbség a ZIL, SLOG, sync és async írás között, ne csodálkozz, ha nem az lesz az eredmény mint amire számítottál. Csak akkor használd, ha pontosan tudod mire jó, különben pénzkidobás lesz a vége.

  4. Ha tudsz, inkább használj az CACHE (L2ARC) lemez helyett RAM-ot.

    • A CACHE lemez használata nem csodaszer és lehet, hogy semmit nem fog gyorsulni a rendszered tőle, viszont van amikor igen. Abban hasonlít az SLOG-ra, hogy nem minden esetben van értelme. Csak akkor használd, ha pontosan tudod mire jó, különben ennek is pénzkidobás lesz a vége.

  1. Sok kicsi sokra megy 12 x 1 > 3 x 10

    • Amivel jelentősen növelhető a teljesítmény az a sok lemez. Ha akarsz például 10TB területet 2 paritás lemezzel akkor sokkal jobb a 3x10TB helyett a 7x2TB lemez és még annál is jobb a 12x1TB.

  2. Egy POOL kihasználtsága legyen lehetőleg 70% alatt.

    • Ez nem csak a ZFS-re igaz, hanem minden fájlrendszerre. Több mindentől függ mikor kezd lassulni, de 70%-kal nem lősz mellé.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Itt a "hw raid szoftverek" alatt mire gondolt a költő? A ZFS a softraidet lecseréli (ez külön fel is van sorolva az md-vel) de a hw RAID-et nem helyettesíti.

Amúgy, a ZFS pont a fentiek miatt storage szervert célokra a legjobb, általános felhasználású rendszereknél kicsit kevésbé, mert megvan a veszélye, hogy az alkalmazás és a ZFS egymás elől eszik el a memóriát. 

Ami itt nincs leírva: a ZFS megfelelő konfiguráció mellett képes valamennyire dinamikusan kezelni a saját memóriaigényét, de jellemzően 80% memória telítettség felett már be kell avatkozni, mert a tapasztalatok szerint nem szereti, ha az alá megy a memória - főleg Linuxon. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Hardw…

Hardware RAID controllers should not be used with ZFS.

A ZFS helyettesíti a HW raid-et, sőt van olyan lemez aminél a módosított firmware-ben ki van kapcsolva az önjavítás, hogy még az se menjen a ZFS alatt. ZFS-hez HBA mód kell, különben a lényegét veszíted el, hibalehetőséget teremtesz és fölöslegesen használod.

A memóriát meg akkor "eszi el" ha rosszul van konfigurálva és méretezve a rendszer. Állítható a ZFS maximális memória használata.

, ha az alá megy a memória - főleg Linuxon. 

Én még nem láttam olyat aki windows alá ZFS-t rak :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

mert megvan a veszélye, hogy az alkalmazás és a ZFS egymás elől eszik el a memóriát. 

A szabad memóriát szépen felhasználja a ZFS cache-nek, amit a programok továbbra is bármikor azonnal le tudnak foglalni. Nem használja el előlük.

Ez független attól, hogy a cache max méretét még állítani is lehet (zfs_arc_max), de alapból "önszabályozó". Ha meg nincs memória a cache számára, hát akkor nem lesz annyi cache.

Nem veszi el a programok elől a memóriát.

de. nagyon is elveszi. utana pedig baratkozhatsz OOMkill baratunkkal. :) (nem a zfs-t fogja lenyirni, talal maganak valamit)
ez marhara nem a linux disk cache. neked uzemeltetokent az a dolgod, hogy beallitsd a memoria limiteket. :)
es igen, pont az ilyen teveszmek terjesztese miatt fosik mindenki a zfs-tol zfs-rol a Zinternetben random leirtaktol :P

#worksforme.

Nem veszi el. Mondjuk én freebsd-n használom. Az "arc cache"-t mint "arc cache" látod foglaltnak, és a programok abba szépen "bele" tudnak foglalni.

Erre egyébként keress rá, én megtaláltam freebsd doksiban is, pfsense doksiban, a solaris doksiban hasonlót. és fórumokon is.

Itt van pl egy blog:

https://medium.com/@PlanB./zfs-arc-and-memory-caching-in-proxmox-explai…

The ARC dynamically adjusts its size based on the memory demands of other processes. If your server has unused RAM, ZFS uses it for caching. However, if another application requires memory, the ARC will release some of its cache to accommodate the request.

AI alapú áttekintés (google):

Yes, ZFS (specifically its cache, called the ARC) will release memory to other processes if they need it. ZFS is designed to use available RAM to improve performance, but it will not starve other applications.

Szerintem innen egyébként a félreértés, hogy "sok memória kell" neki, mert ha valaki 32 vagy 64Gb-tal indítja el, akkor akkor nagy részét "foglaltnak" fogja látni az arc cache számára. Ha csak 2Gb-tal, akkor annyit fog foglaltnak látni. (bizonyos feature-ökhöz meg persze, hogy kell a memória, pl deduplikáció, tömörítés, stb.., vagy jelentős párhuzamos használat...) - De ez nem azt jelenti, hogy az elsőre foglaltnak látszó "arc cache" memória tényleg foglalt, mert az alkalmazásoknak átengedi, ha valamelyik memóriát próbál foglalni.

És ezen felül van lehetőséged beállítani a limiteket is, szükség esetén. 

A téveszmékről egy tök jó cikk, amit párszor már megosztottam itt: https://distrowatch.com/weekly.php?issue=20150420#myth

de, elviszi, es igen, oomkiller fog dolgozni mikor elfogy a ram es a zfs nem tudja olyan gyorsban elengedni, mint a rendszernek kellene.

On 7/10/2025 6:11 PM, Roland wrote:
> imho, killing processes because of arc using too much ram which can't 
> be reclaimed fast enough is a failure in overall memory coordination.
>
> we can set zfs limits as a workaround, yes - but zfs and oomkiller is 
> to blame !!!
>
> 1. zfs should free up memory faster, as memory is also freed from 
> buffers/caches
>
> 2. oomkiller should put pressure on arc or try reclaim pages from that 
> first, instead of killing kvm processes.  maybe oomkiller could be 
> made arc-aware!?
>
> roland

kollega szinten nem ertette miert doglenek a VM-jei. :) hat azert, amit irtam fentebb. 

Jó, valakinek valami nem jó a gépén, és fogalmunk sincs mi van a gépén, és hogy használja. És aki gondolja, hogy a zfs vagy az oomkill tehet a problémáiról.

(Ebből én nem tudok még nagy következtetéseket levonni, mert még az is kiderülhet, hogy teljesen másról van szó.)

De gondolom pont az edge case-ek, és a másfél emberes szükségletek miatt lehet paraméterezni.

Nézd, nem biztos, hogy ebbe a problémába mindenki belefut, bár én nem linux alatt használtam, így ott nincs vele tapasztalatom.

Használok VM-et ZFS-sel, volt hogy több is futott alaposan megtöltve a memóriát, soha semmi problémám nem volt. Freebsd alatt.

Az oomkill-re több megoldás lehet, pl a paraméterezés (amit én is írtam), vagy swap használat, esetleg kvm oldalon is lehet állítani valamit (nem tudjuk mit állított be, és mit csinált akinek a levelét bemásoltad). Tudod Te is, teljes fórumok tudnak hülyeségekről szólni, esetleg túlzó elvárások miatt is. (pl a ZFS "ne használjon" memóriát a mellette futó KVM-ek mellett). Lehet, hogy azon a gépen "annyit" nem lehetett felszabadítani, stb... - A butaság része az lenne, ha látunk egy levelet, és levonjuk a következtetést, hogy mondjuk a ZFS szar.

ZFS alatt a hivatalos az, hogy az ARC nem veszi el a memóriát a futó folyamatok elől. Technikai probléma mégis előfordulhat, én is azt írtam, hogy arra ott a paraméterezés. (miután valaki ténylegesen belefutott bármibe, addig szerintem felesleges hozzányúlni)

Freebsd alatt pl tudomásom szerint nincs is oomkill, máshogy kezeli ezt le.

nem mindenki fut bele.

Ezt próbáltam én is mondani, hogy szerintem ez így lehet. Csak mielőtt valaki megijed, hogy ha zfs-t használ, akkor ki lesznek lőve a folyamatai.

nem kell megijedni. be kell allitani a memoriahasznalatot.
https://klarasystems.com/articles/exploring-swap-on-freebsd/

amugy volt ugyfel, ahol a KSM+USED RAM+ARC kb. 8-10gigaval volt a fizikai RAM meret folott a hypervisoron honapokig, nekik szerencsejuk volt, egyszer sem fogyott el OOMkillig. :)

az illető nem tud magyarázni azon a szinten amire nekem szükségem volna, vagy egyszerűen csak szar tanár > hat... helyetted nem fogja senki megtanulni mondasa
Sok mítosz, sok berögződés keveredik > ha eletedben nem hasznaltad, milyen berogzodeseid vannak? :)

csainalsz par poolt file(ok)bol, aztan megtanulod a kis konzolodon, hogy mi merre.

zpool create testpool /ahol/a/filod/van

 tobb filebol pedig mindenfele vdev/pool felallast ossze tudsz tenni.
man zpool pl. eleg hasznos... :)
 


EXAMPLES
Example 1: Creating a RAID-Z Storage Pool

The following command creates a pool with a single raidz root vdev that consists of six disks:
# zpool create tank raidz sda sdb sdc sdd sde sdf
Example 2: Creating a Mirrored Storage Pool

The following command creates a pool with two mirrors, where each mirror contains two disks:
# zpool create tank mirror sda sdb mirror sdc sdd
Example 3: Creating a ZFS Storage Pool by Using Partitions

The following command creates a non-redundant pool using two disk partitions:
# zpool create tank sda1 sdb2
Example 4: Creating a ZFS Storage Pool by Using Files

The following command creates a non-redundant pool using files. While not recommended, a pool based on files can be useful for experimental purposes.
# zpool create tank /path/to/file/a /path/to/file/b
Example 5: Making a non-mirrored ZFS Storage Pool mirrored

The following command converts an existing single device sda into a mirror by attaching a second device to it, sdb.
# zpool attach tank sda sdb
Example 6: Adding a Mirror to a ZFS Storage Pool

The following command adds two mirrored disks to the pool tank, assuming the pool is already made up of two-way mirrors. The additional space is immediately available to any datasets within the pool.
# zpool add tank mirror sda sdb
Example 7: Listing Available ZFS Storage Pools

The following command lists all available pools on the system. In this case, the pool zion is faulted due to a missing device. The results from this command are similar to the following:

# zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
rpool  19.9G  8.43G  11.4G         -    33%    42%  1.00x  ONLINE  -
tank   61.5G  20.0G  41.5G         -    48%    32%  1.00x  ONLINE  -
zion       -      -      -         -      -      -      -  FAULTED -

Example 8: Destroying a ZFS Storage Pool

The following command destroys the pool tank and any datasets contained within:
# zpool destroy -f tank
Example 9: Exporting a ZFS Storage Pool

The following command exports the devices in pool tank so that they can be relocated or later imported:
# zpool export tank
Example 10: Importing a ZFS Storage Pool

The following command displays available pools, and then imports the pool tank for use on the system. The results from this command are similar to the following:

# zpool import
  pool: tank
    id: 15451357997522795478
 state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:

        tank        ONLINE
          mirror    ONLINE
            sda     ONLINE
            sdb     ONLINE

# zpool import tank

Example 11: Upgrading All ZFS Storage Pools to the Current Version

The following command upgrades all ZFS Storage pools to the current version of the software:

# zpool upgrade -a
This system is currently running ZFS version 2.

Example 12: Managing Hot Spares

The following command creates a new pool with an available hot spare:
# zpool create tank mirror sda sdb spare sdc

If one of the disks were to fail, the pool would be reduced to the degraded state. The failed device can be replaced using the following command:
# zpool replace tank sda sdd

Once the data has been resilvered, the spare is automatically removed and is made available for use should another device fail. The hot spare can be permanently removed from the pool using the following command:
# zpool remove tank sdc
Example 13: Creating a ZFS Pool with Mirrored Separate Intent Logs

The following command creates a ZFS storage pool consisting of two, two-way mirrors and mirrored log devices:
# zpool create pool mirror sda sdb mirror sdc sdd log mirror sde sdf
Example 14: Adding Cache Devices to a ZFS Pool

The following command adds two disks for use as cache devices to a ZFS storage pool:
# zpool add pool cache sdc sdd

Once added, the cache devices gradually fill with content from main memory. Depending on the size of your cache devices, it could take over an hour for them to fill. Capacity and reads can be monitored using the iostat subcommand as follows:
# zpool iostat -v pool 5
Example 15: Removing a Mirrored top-level (Log or Data) Device

The following commands remove the mirrored log device mirror-2 and mirrored top-level data device mirror-1.

Given this configuration:

  pool: tank
 state: ONLINE
 scrub: none requested
config:

         NAME        STATE     READ WRITE CKSUM
         tank        ONLINE       0     0     0
           mirror-0  ONLINE       0     0     0
             sda     ONLINE       0     0     0
             sdb     ONLINE       0     0     0
           mirror-1  ONLINE       0     0     0
             sdc     ONLINE       0     0     0
             sdd     ONLINE       0     0     0
         logs
           mirror-2  ONLINE       0     0     0
             sde     ONLINE       0     0     0
             sdf     ONLINE       0     0     0

The command to remove the mirrored log mirror-2 is:
# zpool remove tank mirror-2

At this point, the log device no longer exists (both sides of the mirror have been removed):

  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

The command to remove the mirrored data mirror-1 is:
# zpool remove tank mirror-1

After mirror-1 has been evacuated, the pool remains redundant, but the total amount of space is reduced:

  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

Example 16: Displaying expanded space on a device

The following command displays the detailed information for the pool data. This pool is comprised of a single raidz vdev where one of its devices increased its capacity by 10 GiB. In this example, the pool will not be able to utilize this extra capacity until all the devices under the raidz vdev have been expanded.

# zpool list -v data
NAME         SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
data        23.9G  14.6G  9.30G         -    48%    61%  1.00x  ONLINE  -
  raidz1    23.9G  14.6G  9.30G         -    48%
    sda         -      -      -         -      -
    sdb         -      -      -       10G      -
    sdc         -      -      -         -      -

Example 17: Adding output columns

Additional columns can be added to the zpool status and zpool iostat output with -c.

# zpool status -c vendor,model,size
   NAME     STATE  READ WRITE CKSUM vendor  model        size
   tank     ONLINE 0    0     0
   mirror-0 ONLINE 0    0     0
   U1       ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U10      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U11      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U12      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U13      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U14      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T

# zpool iostat -vc size
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write  size
----------  -----  -----  -----  -----  -----  -----  ----
rpool       14.6G  54.9G      4     55   250K  2.69M
  sda1      14.6G  54.9G      4     55   250K  2.69M   70G
----------  -----  -----  -----  -----  -----  -----  ----

uana johet: https://manpages.debian.org/unstable/zfsutils-linux/zfs.8.en.html

ha alapok megvannak, akkor kezdhetsz keresgelni, hogy milyen felhasznalasra, mi/miert/hogyan/mennyi valo. az mar a fine tune.

jo szorakozast/tanulast!

Kb. erre gondoltam. Vdev bővítés coki, ECC nem kötelező, hw-raid-re ne pakold, fsck nincs építsd újra backupból, a verziók közötti tételes különbségek ezek:.... Na ilyenekből gondolom van még 2 tucat a törusi tudástárban. Ami intelmeket csak azután fogja fel az ember, h. beszopta személyesen. Mennyivel erőforrás és életidő-takarékosabb lenne, ha ezek össze lennének gyűjtve a "for beginners" okosító videóban!

Ha megkeresed a régi blogomat, abból kiderül, pontosan milyen opciókkal hoztam létre a poolt. Ha azt a parancsot össze tudod rakni magadnak, hogy az pont jó legyen és ne akard megváltoztatni, akkor már nyert ügyed van. Ha majd egyszer változtatni akarsz, majd akkor jobban utánaolvasol.

Hardver része: A Gen10-ben 8 GB RAM van, és dedup nélkül ez bőven elég neki. És amúgy ECC-s, ami szerintem ZFS-től függetlenül is egy jó dolog. Szóval gyenge vason is megy. Hardver RAID tényleg fölösleges. Szerintem nem sok olyan hardver RAID feature van, ami házi felhasználásnál kellene, és ne lehetne ZFS-sel vagy máshogy megoldani (pl. áramprobléma esetére SSD PLP vagy UPS).

most komolyan azt varod el, hogy olyat tanitsanak meg otpercfonok video alatt egy komplett tiering storage megoldas barmilyen alkalmazasi teruletre valo megtervezesere es uzemeltetesere, aki azt sem tudja mi fan terem a block device? :)
amiket itt felsoroltok ott vannak barhol a Zinterneten az elso TLDR leirasban. am ahhoz eloszor tudni kene mi az a vdev (es kb. melyik miert/mire valo), raidz, pool, snapshot, (z)vol(ume), (l2)arc, cache, filesystem... de ezek altalanos alapok ugyebar. megismerkedhetsz veluk barmelyik linuxon egy konzolban, nem kell szetb*nod semmit.

raidz vdev bovites hint: https://github.com/openzfs/zfs/pull/15022

Komplett 5 éves egyetemi kurzus tananyagok fent vannak MIT Opencourseware-n, vagy Computer Architecture a Zürich egyetemen (Livestream - Digital Design and Computer Architecture - ETH Zürich (Spring 2025) - YouTube) 

de egy 5-részes jó(!) ZFS tananyag nem lehet fent jutubon...? :D

De simán, de biztos Te is szoktál olyat csinálni, hogy másfélszeres sebességgel hallgatod az ilyen videókat, egyébként nagyon elhúzzák, és ráadásul nem is teljes. Szoktam én is oktató videókat nézni. De a doksi (szerintem) hatékonyabb, és teljesebb, főleg egy hivatalos doksi.

Ha találsz jó és teljes videó sorozatot a YT-on erről, majd kérlek oszd meg. Én még régebben vettem meg a devops akadémiás ZFS videót, de nem rémlik, hogy megnéztem végül.

navarj, akkor most 5 eves egyetemi kurzust keresel, vagy tldr 5 perces zfs "mindenhato" videot? :)

ha komolyan akarsz vele foglalkozni, akkor igen, lehet, hogy sok evig fogod magadba szivni a tudast.

ha meg nem akarsz vele foglalkozni, akkor veszel egy nast. vagy barebone-t es odaadod egy szakinak, h konfigolja be.

minden masra ott a cheat sheet elso 3 parancsa, vagy a manpage-bol az examples. :)

nem te lennel az elso akinek megborul a zfs otthon :) csak monitoring kerdese. a topiknyitonak volt, tul is elte a tomb. :)

nem bantaskepp, de aki nincs tisztaban a zfs miert es mire jo meg mik a buktatoi (mire nem, milyen eroforrasigenye van), annak:

A - igazabol nincs ra szuksege sem
B - felrak egy proxmoxot vagy truesnast vagy (...) es a feluleten osszeklikkeli, ugyanugy, mint a dmraidet, aztan boldog vele
C = B, csak konzolban, az examples-bol

Vagy D) kezdő üzemeltető, esetleg nem találkozott még ezzel a technológiával, de szívesen megismerkedne vele - viszont nem biztos, hogy végtelen ideje van tanulni.

Én pl úgy tanultam meg a ZFS-t, hogy bekerültem egy céghez, és kiderült, hogy happen to be ZFS alapú szervereik vannak, ami tök fasza, persze, man zpool meg man zfs meg wiki, de azért mocsok jó lenne tudni, hogy ezt most eszik vagy isszák, meg ha veszünk új szervert azon konfiguráljuk-e másképp. Még most, 3 év ZFS használat után se merném azt állítani, hogy értek hozzá - inkább csak szoptam vele rengeteget. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Irodában kellett a sjanpshot a file szerverre, így zfs lett. Anno valami okos videó alapján beállítottam, azóta 1x kellett lemezt cserélni, hiba nélkül lement. Igazából elég probléma mentes a történet részemről. Persze, mire hozzá kell nyúlni, elfelejtek mindent, de mivel írok mindenről jegyzetet, ezért van hová nyúlni.

pont erre jó a truenas

De akinek nincs baja a parancssorral, aki nem akar előre kitalált GUI logikákat, ami korlátoz, annak azt merem mondani, hogy a ZFS parancssorban is eléggé felhasználó barát.

És a másik gondolat: ha GUI előtéted van, az ZFS alapjait akkor sem árt érteni.

korlatoz, vagy segit. (pl, hogy a kolleganak ne kelljen jegyzetet turni) attol fugg honnan nezed. :)
hint: a truenas-ban pont ugyanaz a parancssorod megvan a felulet mellett a zfs-hez. sot, regen a BSD-s verzion (most nem'tom, meg kene nezni) meg a ZFS (meg egyeb mas rendszer szintu) tunables-t is kivezette neked feluletre, hogy el se tudd rontani melyik configba kell beirogatni. plusz a konfig export/importba is bekerult, ha vitted a cuccod masik vasra. :)

Értem, hogy van akinek így egyszerűbb (aki kattintgatni szeret), de önmagában parancssorban is meglepően felhasználó barát a ZFS. Nem biztos, hogy egy GUI mindenkinek annyi pluszt ad.

A ZFS működni fog, a GUI-ban pedig találsz majd három idegesítő hibát, vagy valami korlátozást, és innentől elkezd zavarni majd, hogy minek is az.

De kinek mi válik be.

az a gond, hogy nem mondasz semmit, csak felallitasz latatlanban egy konkluziot valamirol, elore tudod, hogy harom helyen fogja megzavarni a konzolnyomkodasod elmenyfaktorat :) (mikozben truenason is ott a konzol...)
veled ellentetben en productionben uzemeltetek truenast tobbszaz VM alatt. az alapjan mondom azt, amit. :)

Nem mai gyerek lehetsz Te sem, gondolom találkoztál GUI-kkal már, ahol korlátozva voltál, mert lehet már tapasztalatod.

De pl mondok egyet: a truenas scale-ben utáltam, ahogy a konténereket kezelték, kubernetessel erőltetve, és inkább megoldom truenas nélkül.

Ezen felül bug is volt, amire nem emlékszem (ezeket igyekszem elfelejteni, ha már nincs vele dolgom), csak hogy volt vele probléma.

De vegyél elő egy átlagos IOS felületet, és nézd meg korlátozásokat, vagy nézd meg a windows-od, hogy kell telepítened online user nélkül.

De ha engem kérdezel, akkor azt használsz, amit akarsz. :)

Szóval ja, blablablázol. :) 

Tudsz ugye általánosan a GUI-król beszélgetni, és ismered a jelenséget, hogy sokszor a csilli-villi felület a korlátozásokkal jár együtt.

Szóval tudod Te hogy miről beszélek. Szívesen beszélek veled, de hülyeségről vitatkozni erőltetetten, mert "nem akarod érteni", most nem fog beleférni. :)

mit nem ertesz?
mi a loturo koze van a fentinek zfs konzolhoz es a truenasnak az ios-hez?
csapongsz.

ezzel mi bajod?
 

root@truenas:/home/truenas_admin# /sbin/zpool create t raidz1 /dev/vdb /dev/vdc /dev/vdd raidz1 /dev/vde /dev/vdf /dev/vdg

  pool: t
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        t           ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            vdb     ONLINE       0     0     0
            vdc     ONLINE       0     0     0
            vdd     ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            vde     ONLINE       0     0     0
            vdf     ONLINE       0     0     0
            vdg     ONLINE       0     0     0

https://i.imgur.com/YsG8JVB.png

komolyan nem ertem miben akadalyoz. meseld mar el, pls!

:)

arrol, hogy van jo gui meg szar gui, meg only gui.

a truenas gui kifejezetten jo ebbol a szempontbol, sot, project van mar ra, hogy balfasz-kompatibilis gui _is_ legyen hozza, mert egyesek szerint pilotavizsgas.

a kerdes tovabbra is az, hogy a fenti gui miben akadalyoz? miert baj, hogy van, mikor ha konzolkodni akarsz zfs create-kor, minden lehetoseged adott?

a fenti gui miben akadalyoz

Egyszerűen annyi van vele, hogy nincs rá szükség, nekem nem kell. És akkor ne fusson feleslegesen, mert minek? Ennyi. Mit nem lehet ezen megérteni?

Hadd döntsem már el én, hogy akarom a truenast használni, vagy nem. Nem, nem pilóta vizsgás, hanem bugos volt az a verzió, amit én próbáltam. Több helyen is.

Abból indult ez a szál, hogy ncc1701 írta, hogy "irodába kellett neki file server snapshot"-tal, Te jöttél a truenassal. Választható az is, de nem kell hozzá. Ez a véleményem a truenasról, fogadd el. És Te továbbra is azt gondolsz, azt használsz, amit akarsz, komolyan nem értem mit erőlködsz ezen. :)

nem-nem... latom mar mit nem ertesz. pedig leirtam fentebb:
arra jottem a truenassal, hogy neki jegyzeteket kell olvasnia, ha hozza kell nyulni. (neked meg a Linux/BSD-s memory managementrol kene, de ezt most nagyvonaluan engedjuk is el :))
egy truenas guival nem kell jegyzeteket olvasni, klikk klikk finish a diszkcsere, meg az autosnapshot a sambarol :)
ha neked nem kell truenas vagy gui miert beszelsz bele egy truenas-szalba? :) hol a relevancia? :)
itt kellett volna a trollkodast abbahagyni... innentol csak vergodsz, meg ios-ezel...
tovabbra sem latom egy middleware meglete/nem lete miben akadalyoz, ha konzolpornozni vagysz es, hogy ha neked nem kell/nem hasznalod/nem tetszik, es neked nem kell jegyzet hozza, az mitol lesz itt relevans. :)

Jó, akkor jól megmondtad, hogy mindenki a truenast használja, mert az csak klikk-klikk diszkcsere, az a jó megoldás. :) Tudod mit, neked van igazad. :)

Igaz, hogy másnak meg nem vált be, de az nyilván tök hülye, Te tudod a tutit.. :)

Azt írtam, hogy a ZFS pont az, ahol meg kell jegyezni azt a pár dolgot, amit a middleware is tud, és pont ugyanúgy kell parancssorban is használni. Meglepően felhasználóbarát ott is. A middleware meg azt a logikát követi. Aki szeret klikkelgetni, annak ott a middleware, annak hajrá. Aki nem (például máshogy akarja használni a gépét, vagy nem akar GUI korlátozásokba belefutni), az nélküle is meglesz. 

Szerintem értetted ezt Te is, de jó kis gumicsont. :)

eppen erre vannak az example-ok a manualban. azert egy vdev/pool megertese olyannak, aki latott mar storage-et messzirol, fel szemmel, nem rocket science. :) ha meg nincs kepben, lehet nem pont zfs-sel kell elkezdeni a pusztitast tanulast. :) ha meg megis uzemeltetni akarod, ne sporold le a tanulas reszt. szerintem.

Az első poolt én is eldobtam párszor, de szuper doksija van, és egyértelműek az opciók. Úgy értettem, hogy egyáltalán nem meredek a tanulási görbéje, igazából csak használatba kell venni. (rászánni az időt, ami nem az elakadásokkal fog telni.)

Szerintem egyáltalán nem kell hozzá sok memória, ha nincsenek memóriaigényes feature-ök bekapcsolva, mint pl a deduplikáció, és nincs nagy terhelés (sok párhuzamos használat).

ECC memória nem kell, de jó. Az minden fájlrendszernek jó. De itt legalább kiderül a checksum-okkal, ha hiba van.

Szerintem nem érdemes videóból tanulni, a doksik sokkal célravezetőek. A Solaris doksija is jó, de nem 100%-os pl a FreeBSD-hez.

+ Kísérletezés, kipróbálás, játszás.

( ncc1701 | 2025. 08. 06., sze – 17:59 )

Nálam is ilyen régi 3 terás wd redek vannak raid5-ben, igaz, mdadm-al, 103e óra, 84e óra, és 38e óra idővel. Van tartalékban egy, úgyhogy nem piszkálom őket, és semmi kritikus nincs rajtuk amúgy.

( Elbandi v | 2025. 08. 07., cs – 13:01 )

megvan meg az a "bug", hogy a raidz-kbol osszefuzott pool, kiesik egy disk, a csere utan meg az egesz poolt vegig nyalazza? ez nehany T eseten nem akkora gond, de 45x10T-nel mar napok. "feleslegesen", hiszen a nem erintett raidz-k koszonik jol vannak.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

a pontos parameterekre nem emlekszem mar, oj regen volt. a 45 biztos (5x9 raidz), kipottyant a disk, csereltuk, majd 30+ ora volt a rescan. viszont villogott minden mint a karacsonyfa, a gep meg hasznalhatatlan volt. valtottunk hwraid + lvm-re, ott is esett ki disk, de azok az lv-k amik nem az erintett raidben voltak, vigan _hasznalhatoan_ mentek tovabb. 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

valamit nagyon elcsinalhattatok, mert a parity zfs-ben vdev-en belul van. :)

resilverkor raadasul hozza sem nyul a nem hasznalt adathoz. (aka: trim-eltetek-e rendesen mondasa)

egyebkent pedig regota parameterezheto a resilver mennyit terheljen, tehat ha iras/olvasas van, akkor mennyi milisec-re alljon meg mielott tovabb turna a vdev-et, stb.

( muszi v | 2025. 08. 07., cs – 20:04 )

Most azon agyalok, hogy az a 7 év nem vicc

A diszkek már nyilván nem teljesen újak ;-), de ha nincs rajtuk hibás szektor, akkor a cserén nyilván lehet gondolkozni, de aggódni talán még korai. A cégnél nemrég cseréltünk le egy nagy kupac WD Red-et, amik 10-12 évnyi működés után (!) még mindig hibátlanok.