Vika taitaa olla siinä, että noihin hakemistoihin on joku kirjotellut sillon kun zfs ei ole ollu mountattuna ja zfs ei halua mountata koska hakemisto ei ole täysin tyhjä. Eli liipases noista filut/hakemistot mäkeen (tarkasta ensin, onko mitään tärkeää) ja kokeile uusiks mounttaamista.
/data hakemisto täytyy olla täysin tyhjä. Toki voit ensin kokeilla esim zfs mount -a -O (overlay mount, eli sallii ei tyhjien hakemistojen päälle mounttaamisen).
Voisit kokeilla importata poolin tilapäisesti eri paikkaan niin näät onko siellä kaikki tallessa.
Esim. zpool import -R /foo -o cachefile= [poolinnimi]
Jos tuon jälkeen kaikki data on tallessa mitä pitääkin niin tyhjennät /data hakemiston täysin joko poistamalla alla olevat röyhnät tai heität talteen johonkin toiseen paikkaan.
Onko vinkkiä miten tuosta zfs poolista vois ottaa backupin -> ulkoiselle tai sisäiselle levylle. Lähinnä eka backup ois full ja sen jälkeen muuttuneita tietoja vain lisättäs.
Onhan purkki bootattu vastaavan version moduleilla ettei ole vanhalla versiolla?
Omassa purkissa jostain syystä 0.8.1 sekoilee niin, että jos ei initramfs ole sisällytetty zfs kikkareita niin ei löydä pooleja lainkaan vaikka zfs on vain ja ainoastaan data-levyillä käytössä.
Tässä kai tulee esiin ZFS on Linuxin suurin heikkous: se ei ole natiivisti osa linuxia vaan asennetaan jollain kernel-moduuli-kludgella kerneliin. Kun kernel päivittyy, vanhat zfs-moduulit ei (useinkaan?) enää toimi ja zfs ei lähde bootatessa tulille. Kaikki näyttää menetetyltä.
Jos kone vain ajettiin hallitusti alas, niin zfs-levyt on todennäköisesti täysin ehjiä. Ongelma on vain siinä, miten itse zfs saadaan käyntiin uudella kernelillä ja tämä voi tilanteesta riippuen vaatia enemmän tai vähemmän loitsuja. Kun zfs on saatu taas henkiin, niin kaikki datakin kyllä löytyy.
Ei kannata päivittää zfs-levypalvelimen kerneliä tai bootata palvelinta turhan päiten.
Tässä kai tulee esiin ZFS on Linuxin suurin heikkous: se ei ole natiivisti osa linuxia vaan asennetaan jollain kernel-moduuli-kludgella kerneliin. Kun kernel päivittyy, vanhat zfs-moduulit ei (useinkaan?) enää toimi ja zfs ei lähde bootatessa tulille. Kaikki näyttää menetetyltä.
Jos kone vain ajettiin hallitusti alas, niin zfs-levyt on todennäköisesti täysin ehjiä. Ongelma on vain siinä, miten itse zfs saadaan käyntiin uudella kernelillä ja tämä voi tilanteesta riippuen vaatia enemmän tai vähemmän loitsuja. Kun zfs on saatu taas henkiin, niin kaikki datakin kyllä löytyy.
Ei kannata päivittää zfs-levypalvelimen kerneliä tai bootata palvelinta turhan päiten.
Itsellä Ubuntu 18.04 LTS ajossa ja tuota päivittelen ja boottailen muutaman kerran vuodessa. ZFS vain datalevyillä käytössä ja ei ole ongelmia ollut poolien löytymisessä bootin jälkeen.
Tässä kai tulee esiin ZFS on Linuxin suurin heikkous: se ei ole natiivisti osa linuxia vaan asennetaan jollain kernel-moduuli-kludgella kerneliin. Kun kernel päivittyy, vanhat zfs-moduulit ei (useinkaan?) enää toimi ja zfs ei lähde bootatessa tulille. Kaikki näyttää menetetyltä.
Tässä kai tulee esiin ZFS on Linuxin suurin heikkous: se ei ole natiivisti osa linuxia vaan asennetaan jollain kernel-moduuli-kludgella kerneliin. Kun kernel päivittyy, vanhat zfs-moduulit ei (useinkaan?) enää toimi ja zfs ei lähde bootatessa tulille. Kaikki näyttää menetetyltä.
Mjaa mulla on kernel päivityksissä kiltisti käännellyt uudet modulit initrdtä varten ja ei muuta kuin kovaa ajoa. Jos päivität kernelin käsin niin joudut toki kääntämään modulit uutta kerneliä vasten ja päivittämään initrd:n käsin. Ja kernel module ei ole kludge edelleenkään
Toki nää ubuntun päivitykset laahaa perässä (ymmärrettävästi) jonkin verran bleeding edgeä. Jos bleeding edgeä haluaa niin sitten joutuu säätämään.
Mjaa mulla on kernel päivityksissä kiltisti käännellyt uudet modulit initrdtä varten ja ei muuta kuin kovaa ajoa. Jos päivität kernelin käsin niin joudut toki kääntämään modulit uutta kerneliä vasten ja päivittämään initrd:n käsin. Ja kernel module ei ole kludge edelleenkään
Tätä on varmaan parannettu viime aikoina, kun ZFS:stä on tullut enemmän valtavirtaa. Joskus kun ZFS:n joutui asentamaan käsin, niin myös päivitykset teettivät enemmän työtä.
Oleellinen asia kuitenkin on, että säätämisen jälkeen ZFS-levyt on aina löytyneet ehjinä.
Milloin nuo smart testit on ajettu ja miltä tämän hetken arvot näyttää tuolle poolista tippuneelle levylle? Onko jopa tuo wd red minkä type listauksessa on unknown?
E: greenihän tuo oli
Vaihtaisin joka tapauksessa uutta limppua tilalle vaikka voisikin elpyä pooliin uudelleen liittämisen ja resilverin jälkeen (olettaen että smart on kunnossa).
Smart tiedoissa näkyy levyn WWN id mistä tuo aiemmassa screenshotissa näkyvä levyn tunniste tulee (...344cb). Symlinkin tarkistus itse laitteen nimeen mikä näkyy aiemman kuvan smart tietojen ohessa jo neuvottiinkin.
E: WWN löytyy myös fyysisesti levyn päällä olevasta tarrasta, jolloin oikea levy helppo löytää, jos useita samanlaisia ja muuten ei sijainti tiedossa.
Itselläkin samaa ongelmaa, ja nimenomaan proxmoxissa. Virtuaalikoneet toimivat oikein jees mutta katsottaessa zfs-poolissa olevia kansioita ne näyttävät tyhjiltä. Ilmeisesti tää ongelma sulla ratkesi exporttaamalla ja importtaamalla zfs-pooli uudelleen. Mikäköhän tuon ongelman oikein aiheutti. Pitääköhän tässä ruveta katselemaan jotain toista levyjärjestelmää jos zfs proxmoxissa alkaa kenkkuilla. Olisiko hyviä ehdotuksia? btrfs vaikuttaa hyvältä mutta ovatko sen ongelmat varsinkin raidia käytettäessä jo korjattu. Ainakin joskus suositeltiin että btrfs ei käytettäisi raid-pakoissa.
Itselläkin samaa ongelmaa, ja nimenomaan proxmoxissa. Virtuaalikoneet toimivat oikein jees mutta katsottaessa zfs-poolissa olevia kansioita ne näyttävät tyhjiltä. Ilmeisesti tää ongelma sulla ratkesi exporttaamalla ja importtaamalla zfs-pooli uudelleen. Mikäköhän tuon ongelman oikein aiheutti. Pitääköhän tässä ruveta katselemaan jotain toista levyjärjestelmää jos zfs proxmoxissa alkaa kenkkuilla. Olisiko hyviä ehdotuksia?
Muuten hyvä mutta itselläni olisi tarkoitus rakentaa proxmoxin päälle ha-virtualisointiklusteri. Näillänäkymin tulee päädyttyä joko Ceph tiedostojärjestelmään tai sitten jaettua iSCSI:llä eräästä promisen wessraid levypalvelimesta levypintaa virtuaalikoneille. Hyper-converged Infrastructure - Proxmox VE File system - Ceph
Pientä askartelua ZFS:n kanssa. Rakentelin kasasta vanhoja levyjä 4x1 TB raidz1-poolin. Haasteena oli, että levyillä oli vanhaa dataa, esim. valokuvien varmuuskopioita, joita ei ihan läpikäymättä viitsinyt jyrätä sileäksi.
Poolin rakennetta voi muuttaa myös vaihtamalla olemassaolevat levyt isompiin yksi kerrallaan. Lisää levytilaa tosin tulee vasta, kun mirror, raid1z tai raid2z-kokonaisuus on kokonaan kasvatettu isommaksi.
...on kyllä hyvä vinkki!
Ensin tyhjensin n. 250 GB levyjä isommille ja näin sain luotua neljän levyn raidz1-pakan, jonka lopulta kasvatin 4x1TB-pakaksi. Poolin kasvattaminen vaati zpool online -e -komennon. Yksi sakkokierroskin tuli otettua, kun -o ashift=12 unohtui poolia luodessa...
Pientä jippoilua joutui harjoittamaan, jotta 1 TB levyt sai tyhjennettyä uudelle pakalle ja kasvatettua sen kokoa. Tässä auttoi se, että vdev:ien ei ole aivan pakko olla fyysisiä levyjä. vdev:nä voi käyttää esim. lvm:llä kahdesta levystä muodostettua RAID0-pakkaa tai jopa kahta erillistä osiota isolla levyllä (1 TB -> 2 kpl 500 GB osio). Jälkimmäisellä menetetään toki osittain raidz1:n turva.
Lopullisesta 4x1 TB-pakasta tuli yllättävänkin nopea:
Koodi:
$ dd if=VirtWin.bin of=/dev/null bs=1M
37132+0 records in
37132+0 records out
38935724032 bytes (39 GB, 36 GiB) copied, 100.562 s, 387 MB/s
Nyt RAID0 oli vdev:nä vain tilapäiskäytössä mutta olisiko pysyvässäkään käytössä ongelmaa jos levypaikkoja vain riittää? Sillä saisi vähän joustavuutta pakan kasvatukseen, kun 3-4 levyn pakkaa voisi kasvattaa ostamalla vain kaksi uutta levyä ja rakentamalla vanhoista RAID0-vdev:jä.
RAID0:n saa zfs:n vdev:ksi tällaisella LVM-rakenteella:
Koodi:
# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/sd_250A_crypt tila lvm2 a-- <232.87g 16.00m
/dev/mapper/sd_250B_crypt tila lvm2 a-- <232.87g 16.00m
# vgs
VG #PV #LV #SN Attr VSize VFree
tila 2 1 0 wz--n- 465.73g 32.00m
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
vaja tila -wi-a----- 465.70g
Kaksi PV:tä on siis yhdistetty VG:ksi tila, luotu sinne LV vaja ja muodostuvan /dev/mapper/tila-vaja:n voi ottaa zfs:n käyttöön zpool replace-komennolla.
Tuosta puuttuu vielä historia aspekti joka on todella tärkeä tietynlaisissa tilanteissa. Eli pystyy palauttamaan samoista tiedostoista vanhat versiot. Aina tiedon korruptoituminen (vahingossa, tahallaan tms) ei välttämättä ilmene heti. Vain se, että on mahdollisuus poimia historiasta sopivat versiot auttaa tähän.
Menee jo vähän toistoksi, mutta zfs:n snapshotit on käteviä tässäkin. Se kun on kaiken aikaa käyttäjän ulottuvilla ilman että mitään tarvitsee varsinaisesti palauttaa mistään. Käyttäjä pystyy siis itse tarkistamaan mitä oikein on tullut kämmellettyä ja palauttamaan vaikka yksittäisiä tiedostoja.
Snapshotit löytyvät levyn juurihakemistossa olevasta piilotetusta .zfs-hakemistosta:
This book is intended for anyone responsible for setting up and administering Oracle ZFS file systems. Topics are described for both SPARC and x86 based systems, where appropriate.
docs.oracle.com
Snapshots of file systems are accessible in the .zfs/snapshot directory within the root of the file system. For example, if tank/home/matt is mounted on /home/matt, then the tank/home/matt@thursday snapshot data is accessible in the /home/matt/.zfs/snapshot/thursday directory.
.zfs/ on niin hyvin piilotettu, että Linuxin komentorivilläkään se ei näy tavallisilla ls:n optioilla, mutta kun sen kirjoittaa käsin, niin hakemisto sisältöineen löytyy. Mahtaakohan sama toimia Windows-jakojenkin läpi?
ZFS snapshotit toimivat smb jaoissa previous versions kansion ominaisuuksissa windowsin puolella. Voi palauttaa tai kopioida sieltä vapaasti. Eli siis vanha kunnon shadowcopy ominaisuus.
Menee jo vähän toistoksi, mutta zfs:n snapshotit on käteviä tässäkin. Se kun on kaiken aikaa käyttäjän ulottuvilla ilman että mitään tarvitsee varsinaisesti palauttaa mistään. Käyttäjä pystyy siis itse tarkistamaan mitä oikein on tullut kämmellettyä ja palauttamaan vaikka yksittäisiä tiedostoja.
Eri tiedostojärjestelmien snapshotit on käteviä ja niitä aktiivisesti käytetään. Mutta malware / hyökkääjä / sabotaasintekijä on varmasti tietoinen kyseisestä ominaisuudesta. Lisäksi ne tietenkin sijaitsevat samassa tiedostojärjestelmässä. Mutta kyllä, RAIDatussa ympäristössä niistä on tietyissä tapauksissa merkittävää hyötyä, koska tekeävät palauttamisen todella nopeaksi ja helpoksi.
Kun puhuttiin tuossa överiksi vetämisestä, niin tietysti realtime journaling on se ultimate optio. Siinä kaikki levykirjoitukset tallennetaan logiin, josta voidaan sitten rullata vaikka yksittäisen lohkon tarkkuudella kirjoituksia takaisinpäin haluttuun ajankohtaan. Tämähän ei poikkea esim. tietokannan tai tiedostojärjestelmän full journal optiosta mitenkään, kopio journalista vaan säästetään eikä ylikirjoiteta. On näitäkin, joskus harvoin todella hyödyllisiä. Mutta voivat olla tosi tärkeitä mm. audit trailin tapauksessa. Koska jos jotain on kirjoitettu levylle, sitä ei voi enää jälkikäteen helposti hukata, tai tuhota mm. tiedostojärjestelmään tehtyjä tilapäisiä muutoksia tms. - Voipi olla korvaamaton apu jos joudutaan jotain analyysiä tekemään järjestelmästä jälkikäteen. Toisaalta se on kosmisen raskasta ja kallista, mutta elämä on.
Mahtaisiko täältä löytyä ZFS:n päälle enemmän ymmärtäviä? Proxmox-hostissa pyörii Ubuntu Server 20.04.4 LTS -virtuaalikone, johon olen liittänyt neljä 10 TB HDD-lättyä SCSI-levyinä. Tuo neljän levyn pakka on peilattuna ja jaettuna, eli RAID 10 vastaavassa jaottelussa. Nyt on käynyt joko sähkökatkos tai vaihtoehtoisesti olen pysäyttänyt virtuaalikoneen exporttaamatta poolia, enkä saa enää poolia importattua.
Koodi:
user@mannas:~$ sudo zpool import storage10
cannot import 'storage10': I/O error
Recovery is possible, but will result in some data loss.
Returning the pool to its state as of Wed 24 Aug 2022 06:06:10 PM UTC
should correct the problem. Approximately 17 minutes of data
must be discarded, irreversibly. After rewind, at least
one persistent user-data error will remain. Recovery can be attempted
by executing 'zpool import -F storage10'. A scrub of the pool
is strongly recommended after recovery.
user@mannas:~$ sudo zpool import -Fn storage10
Would be able to return storage10 to its state as of Wed 24 Aug 2022 06:06:10 PM UTC.
Would discard approximately 17 minutes of transactions.
user@mannas:~$ sudo zpool import -F storage10
Tuon jälkeen terminaali jää jumiin. Saan kyllä SSH:llä avattua toisen yhteyden ja kone on muuten käytettävissä. Kuvittelin tuon ensin tekevän taustalla jotain, ja jaksoin odotella kuusi vuorokautta, mutta lopulta atopilla tarkastaessani ei konella ollut minkäänlaista levyaktiviteettia kyseisen pakan levyillä. SMART-tiedot levyillä on ihan ok.
Komento zdb -e storage10 -ul antoi seuraavanlaisen tuloksen:
Tuosta pistää nyt ensimmäisenä silmään, että tuossa mainitaan ainoastaan levyt sdb ja sde, mutta pooliin kuuluvista sdc:stä ja sdd:stä ei ole mitään mainintaa. Eikö tuossa kuitenkin pitäisi näkyä kaikki neljä? Kyseiset levyt ovat kuitenkin virtuaalikoneeseen liitettynä kun tarkastin komennoilla lsblk ja ls /dev/disk/by-id/ . Samoin dumpe2fs /dev/sdX1 antaa kaikille levyille identtisen tuloksen:
Koodi:
dumpe2fs 1.45.5 (07-Jan-2020)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdd1
Couldn't find valid filesystem superblock.
/dev/sdd1 contains a zfs_member file system labelled 'storage10'
Usean päivän googlaamisella vastaantulleita vinkkejä:
- echo 1 > /sys/module/zfs/parameters/zfs_recover
- /etc/zfs/zpool.cache poistaminen/uudellennimeäminen
- zpool import -FX storage 10 <- manuaali kertoo X:stä: "WARNING: This option can be extremely hazardous to the health of your pool and should only be used as a last resort."
- poolin importtaus parametrillä -T ja txg-arvolla
Asiasta enempää ymmärtämättä en uskalla lähteä noita summamutikassa kokeilemaan, jotta en pahenna tilannetta. Viime kädessä toki varmuuskopiot löytyy, mutta ovat alkukesältä ja mielelläni pelastaisin kaiken datan vaikka vähän joutuisi vaivaa näkemään ja aikaa käyttämään.
Mahtaisiko täältä löytyä ZFS:n päälle enemmän ymmärtäviä? Proxmox-hostissa pyörii Ubuntu Server 20.04.4 LTS -virtuaalikone, johon olen liittänyt neljä 10 TB HDD-lättyä SCSI-levyinä. Tuo neljän levyn pakka on peilattuna ja jaettuna, eli RAID 10 vastaavassa jaottelussa. Nyt on käynyt joko sähkökatkos tai vaihtoehtoisesti olen pysäyttänyt virtuaalikoneen exporttaamatta poolia, enkä saa enää poolia importattua.
...
Asiasta enempää ymmärtämättä en uskalla lähteä noita summamutikassa kokeilemaan, jotta en pahenna tilannetta. Viime kädessä toki varmuuskopiot löytyy, mutta ovat alkukesältä ja mielelläni pelastaisin kaiken datan vaikka vähän joutuisi vaivaa näkemään ja aikaa käyttämään.
Tämä tilanne on varmaan jo ohi mutta vastaisen varalle, kannattaa katsoa myös zpool status
tai zpool status <pool>
josko siitä saisi lisätietoa, mikä poolia vaivaa.
Oraclen ZFS-dokumentaatiostakin saattaa olla iloa:
After a pool has been identified for import, you can import it by specifying the name of the pool or its numeric identifier as an argument to the zpool import command.
docs.oracle.com
Esimerkiksi import read-only:nä voi olla hyvä ajatus tilannetta selvitellessä: zpool import -o readonly=on <pool>
Saisko vielä varmistuksen ennen kuin alan hommiin? ZFS on rullannut Ubuntu-serverissä n. kaksi vuotta ja ekaa kertaa tekemässä tällaista.
Mulla on kahden levyn mirror-vdev, missä 3TB ja 4TB levyt:
user@server:~$ zpool status
pool: hddpool
state: ONLINE
scan: scrub repaired 0B in 06:33:51 with 0 errors on Sun Jan 15 09:57:52 2023
config:
NAME STATE READ WRITE CKSUM
hddpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7PU8HFK ONLINE 0 0 0
ata-WDC_WD40EFRX-68N32N0_WD-WCC7K2KYJZ6Y ONLINE 0 0 0
errors: No known data errors
Ostin 4 teran Ironwolfin millä korvata tuo vanha 3-terainen. Ajan sille juuri badblocksia ennen kuin lisään sen pooliin, smart-testit oli ok.
Ilmeisesti riittää että:
(autoexpand on poolissa valmiiksi päällä)
1) Partedilla mklabel GPT uudelle levylle
2) Varmuuden vuoksi vielä scrub
3) zpool offline ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7PU8HFK
4) zpool replace hddpool ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7PU8HFK /dev/disk/by-id/uusi_Ironwolf
Kannattaako bootata ja ottaa vanha levy fyysisesti irti vaiheiden 3 ja 4 välissä, vai onko tällä mitään väliä?
Mulla ei ole levyä mille backupata koko poolia, vaan pelkästään tärkeimmät (~100G) on ulkoisella levyllä. Jos jotain menee pieleen, mirror lie edelleen tallessa&olemassa tuolla vanhalla 3-teraisella? Eli voinko lyödä sen kiinni toiseen koneeseen ja sanoa zpool import palautusta varten?
Thanks! Eli zfs käskee gpt:ksi jo täysin raa'ankin levyn. Monissa tutoriaaleissa/ulkoketjuissa käskettiin asematkin kopsata etukäteen mutta se nyt varsinkin ois hyvin tarpeetonta tässä. Laitetaan menemään!
Ubuntulle olen tehnyt itselleni tällaisen ohjeen rikkonaisen levyn vaihtoa varten. Ei tavitse joka kerta kaivella ohjeita netistä, ja muistella, miten homma menikään. Samalla kaavalla toimii myös ei rikkonaisen levyn vaihdot.
Laitan tähän, jos tästä olisi vaikka jollekkin joskus hyötyä.
Joskus aikaisemmin levyä vaihtaessani vaati tuon gpt osiotaulun luomisen, muuten tuli herja aiheesta. Tilanne voi olla nykyisin muuttunut.
Koodi:
- Irroita vanha levy Pakasta:
sudo zpool offline NAS /dev/disk/by-id/ata-WDC_WD20EFRX-68AX9N0_WD-WMC301176346
(jos levy kokonaan rikki eikä yhditetty koneeseen, käytä komentoa:
sudo zdb
näin saat levyn guid numeron, jota käytät irroittamiseen ja levyn korvaamiseen (numero korvaa koko "NAS "jälkeisen osan).
- Vaihda uusi levy koneeseen.
- Luo vaihdetulle levylle uusi "gpt" osiotaulu gpartedilla (Laite --> luo osiotaulu... --> gpt)
- Etsi uuden levy nimi komennolla:
ls -lah /dev/disk/by-id
- Korva vanha levy uudella zfs pakkaan (id: vanha/uusi):
sudo zpool replace NAS /dev/disk/by-id/ata-WDC_WD20EFRX-68AX9N0_WD-WMC301176346 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K5XPSL7C
(tarvittaessa käytä quid numeroa korvattavan levyn polkuna).
- Anna pakan korjaantua. Aikaa menee n. 3 tuntia
Laita gsmartcontrollista "enable auto offline data collection" päälle
Vaihdoimpa tässä zfs:n btrfs:ään omissa palvelimissani, tärkeimmät syyt vaihtoon olivat levyjen lisääminen raidiin huoletta, zfs:ssä tuo ei onnistu, lisäksi kun zfs:ää ei ole integroitu suoraan kerneliin aiheutti tuo joskus melko mielenkiintoisia tilanteita päivitettäessä. Hypervisorina siis proxmox, mutta olen siirtänyt muutkin serverit tuota käyttämään, muistaakseni btrfs:n käyttömahdollisuus lisättiin proxmoxiin hiljattain. Pahimmat ongelmat raidiin liittyen, lähinnä tasot 5 ja 6 tuntuvat korjatun viimevuosina, omassa käytössä raid10 pakalla ollut hyvin vakaa.
Vaihdoimpa tässä zfs:n btrfs:ään omissa palvelimissani, tärkeimmät syyt vaihtoon olivat levyjen lisääminen raidiin huoletta, zfs:ssä tuo ei onnistu, lisäksi kun zfs:ää ei ole integroitu suoraan kerneliin aiheutti tuo joskus melko mielenkiintoisia tilanteita päivitettäessä. Hypervisorina siis proxmox, mutta olen siirtänyt muutkin serverit tuota käyttämään, muistaakseni btrfs:n käyttömahdollisuus lisättiin proxmoxiin hiljattain. Pahimmat ongelmat raidiin liittyen, lähinnä tasot 5 ja 6 tuntuvat korjatun viimevuosina, omassa käytössä raid10 pakalla ollut hyvin vakaa.
Juu, jos raid 0, 1 ja 10 on käytössä, btrfs on ihan hyvä valinta. raid 5 ja 6 välttäisin tuotantokäytössä. Jos ei ole vielä ongelmia tullut sinulla niin hyvä.
ZFS:ssä homelab käytössä rajoitteena on tuo yksittäisten levyjen lisääminen olemassa olevaan z1,z2 tai z3 pooliin on rajoitteena joka onneksi poistunee varmaan tämän vuoden sisällä suurimmasta osasta käyttiksiä. Jos sen haluaa jo nyt ottaa käyttöön, pitää vähän kikkailla.
Itse korjasin aikoinaan hommamalla suoraan 8 levyä ja tein niistä yhtenäisen poolin ja sitä mukaa kun on levyjä hajonnut niin pienempiä vaihtelin ja kasvatin kapasiteetin aina pienmimmän levyn mukaan. Nyt kaikki levyt on jo saman kokoisia ja lisätilalle ei ole ollut tarvetta, niin sitä mukaa kun levyt poksahtelee, niin vaihtelen niitä uusiin.
Tällä hetkella pohdin että josko vaihtaisin seuraavan rikkoutuneen levyn tilalle sata ssd:n... Mutta kun ei ole kiire tällä hetkellä, niin en ole ostanut. Toinen vaihtoehto olisi vaihtaa kerralla kaikki yksitellen, mutta sen hinta on aika hapokas vielä (ja sille ei ole aikuisten oikeasti mitään syytä nykyisellä emolla).
Parempi 2.5" nas koppa olisi hakusessa, mutta ei ole tullut vielä vastaan...