ZFS-levyjärjestelmä

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.
 
Mites tuosta saa katottu kaikki mitä näkyy? Kun ekassa viestissä on sisältö mitä niissä näkyy ja ei siellä oo oikeastaan mitään.
 
/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).
 
Kaikki kyllä mounttas kun tuon -A -O ajoin, mutta edelleen kansiot tyhjiä..
 
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.
 
Otithan ensin export, sitten import tyhjään hakemistoon ja tarkastit, että zfs get mounted näyttää value kohdassa yes?
 
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ä.
Jos kyse olis pelkästään tuosta niin sehän olis liiankin helppo korjata, mutta kun ei ole.
 
Ubuntu linuxilla on se hyvä puoli että kun kerran on pystyssä niin ei tarvii buutata 10 vuoteen jos ei halua. Live kernel update rokkaa...
 
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ä.
 
Mitäs tuohon osais tehdä?

upload_2019-7-16_19-36-55.png


upload_2019-7-16_19-38-21.png
 
Mitäs tuohon osais tehdä?

upload_2019-7-16_19-36-55.png


upload_2019-7-16_19-38-21.png

Vaihda ehjä levy tilalle?

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).
 
Viimeksi muokattu:
Juuri äsken ajoin smartin. WD Greeni..

Eihän tuo näytä että olevinaan ois mitään vikaa jos tuo on nyt oikea levy. Miten tuosta ottaa selvää mikä on se "viallinen"

Koodi:
=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD20EARX-00PASB0
Serial Number:   
LU WWN Device Id: 5 0014ee 002d344cb
Firmware Version: 51.0AB51
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Jul 16 19:54:16 2019 EEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x84) Offline data collection activity
                                        was suspended by an interrupting command                                                                                                                                                                                                                                                                                                                                                            from host.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (37980) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off supp                                                                                                                                                                                                                                                                                                                                                           ort.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 366) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x3035) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

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       -                                                                                                                                                                                                                                                                                                                                                                  0
  3 Spin_Up_Time            0x0027   185   167   021    Pre-fail  Always       -                                                                                                                                                                                                                                                                                                                                                                  5708
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -                                                                                                                                                                                                                                                                                                                                                                  459
  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   096   096   000    Old_age   Always       -                                                                                                                                                                                                                                                                                                                                                                  3390
 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       -                                                                                                                                                                                                                                                                                                                                                                  278
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -                                                                                                                                                                                                                                                                                                                                                                  152
193 Load_Cycle_Count        0x0032   167   167   000    Old_age   Always       -                                                                                                                                                                                                                                                                                                                                                                  99276
194 Temperature_Celsius     0x0022   120   106   000    Old_age   Always       -                                                                                                                                                                                                                                                                                                                                                                  30
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   200   200   000    Old_age   Offline      -                                                                                                                                                                                                                                                                                                                                                                  0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -                                                                                                                                                                                                                                                                                                                                                                  0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -                                                                                                                                                                                                                                                                                                                                                                  0

SMART Error Log Version: 1
ATA Error Count: 1
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 1 occurred at disk power-on lifetime: 1721 hours (71 days + 17 hours)
  When the command that caused the error occurred, the device was active or idle                                                                                                                                                                                                                                                                                                                                                           .

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 01 00 00 00 a0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  b0 d6 01 e0 4f c2 a0 00      00:00:36.679  SMART WRITE LOG
  ec 00 01 00 00 00 a0 00      00:00:36.675  IDENTIFY DEVICE

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA                                                                                                                                                                                                                                                                                                                                                           _of_first_error
# 1  Short offline       Completed without error       00%      2269         -
# 2  Short offline       Completed without error       00%      2249         -
# 3  Short offline       Completed without error       00%      2226         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
 
Tökkäät vaan konsoliin ls -l /dev/disk/by-id/... litanian niin näät mihin se on symlink
 
Joo sain onlineen mut pitää tilata levyjä tilalla , kun näyttää olevan jo ongelmia.
 
Juuri äsken ajoin smartin. WD Greeni..

Eihän tuo näytä että olevinaan ois mitään vikaa jos tuo on nyt oikea levy. Miten tuosta ottaa selvää mikä on se "viallinen”

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.
 
Viimeksi muokattu:
Mitähän ihmettä tapahtu proxmoxissa, kun boottas upgraden jälkeen niin mitää ei näy enää mountti kansioissa??

zfs kyllä näyttää että dataa siellä ois:

Koodi:
NAME                           USED  AVAIL  REFER  MOUNTPOINT
data                          2.19T  3.00T   199K  /data
data/image                     170K  3.00T   170K  /data/image
data/iso                      6.45G  3.00T  6.45G  /data/iso
data/store                    2.18T  3.00T   199K  /data/store
data/store/subvol-100-disk-0  2.18T  2.70T  2.18T  /data/store/subvol-100-disk-0
data/subvol-100-disk-0         863M  7.16G   863M  /data/subvol-100-disk-0
vm                            98.1G   117G   333M  /vm
vm/vm-101-disk-0              23.5G   136G  2.85G  -
vm/vm-102-disk-0              74.3G   135G  56.4G  -

mutta jos käy tuolla /data kansiossa löytyy vain:

root@pve:/data# ls -R
.:
image  iso  store  subvol-100-disk-0

./image:

./iso:
dump  images  template

./iso/dump:

./iso/images:

./iso/template:
cache  iso

./iso/template/cache:
debian-9-turnkey-fileserver_15.0-1_amd64.tar.gz

./iso/template/iso:

./store:
subvol-100-disk-0

./store/subvol-100-disk-0:

./subvol-100-disk-0:
dev  store

./subvol-100-disk-0/dev:

./subvol-100-disk-0/store:
root@pve:/data#
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?

Olisikohan tämä luotettava:
Oracle Solaris 11 | Oracle
Olisi ainakin natiivi tuki sekä ZFS:lle että VirtualBox:lle, eikä mikään teippi-&purkkaviritys.

Eikö tuon lisenssi ole nykyään ilmainen mutta rahalla saa ostaa premium-tukea?
 
Olisikohan tämä luotettava:
Oracle Solaris 11 | Oracle
Olisi ainakin natiivi tuki sekä ZFS:lle että VirtualBox:lle, eikä mikään teippi-&purkkaviritys.

Eikö tuon lisenssi ole nykyään ilmainen mutta rahalla saa ostaa premium-tukea?
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.

Tämä...
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.
 
Siirretäänpä tämä varmuuskopioinnista tänne ZFS-ketjuun
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:

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:
Koodi:
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'storage10'
    state: 0
    txg: 1810497
    pool_guid: 1132069552159114054
    errata: 0
    hostid: 1248653330
    hostname: 'mannas'
    top_guid: 7250324418342711373
    guid: 6821261089127885478
    vdev_children: 2
    vdev_tree:
        type: 'mirror'
        id: 1
        guid: 7250324418342711373
        metaslab_array: 72
        metaslab_shift: 34
        ashift: 12
        asize: 10000816144384
        is_log: 0
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 12005692109919538167
            path: '/dev/sdb1'
            whole_disk: 1
            DTL: 948
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 6821261089127885478
            path: '/dev/sde1'
            whole_disk: 1
            DTL: 947
            create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
    labels = 0 1 2 3
    Uberblock[0]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803648
        guid_sum = 7585982447284902646
        timestamp = 1659984882 UTC = Mon Aug  8 18:54:42 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[1]
        magic = 0000000000bab10c
        version = 5000
        txg = 1810497
        guid_sum = 7585982447284902646
        timestamp = 1661364370 UTC = Wed Aug 24 18:06:10 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[2]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803682
        guid_sum = 7585982447284902646
        timestamp = 1659985056 UTC = Mon Aug  8 18:57:36 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[3]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803683
        guid_sum = 7585982447284902646
        timestamp = 1659985061 UTC = Mon Aug  8 18:57:41 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[4]
        magic = 0000000000bab10c
        version = 5000
        txg = 1810468
        guid_sum = 7585982447284902646
        timestamp = 1660019594 UTC = Tue Aug  9 04:33:14 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[5]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803685
        guid_sum = 7585982447284902646
        timestamp = 1659985072 UTC = Mon Aug  8 18:57:52 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[6]
        magic = 0000000000bab10c
        version = 5000
        txg = 1810470
        guid_sum = 7585982447284902646
        timestamp = 1661353455 UTC = Wed Aug 24 15:04:15 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[7]
        magic = 0000000000bab10c
        version = 5000
        txg = 1812807
        guid_sum = 7585982447284902646
        timestamp = 1661365395 UTC = Wed Aug 24 18:23:15 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[8]
        magic = 0000000000bab10c
        version = 5000
        txg = 1810472
        guid_sum = 7585982447284902646
        timestamp = 1661353456 UTC = Wed Aug 24 15:04:16 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[9]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803593
        guid_sum = 7585982447284902646
        timestamp = 1659984601 UTC = Mon Aug  8 18:50:01 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[10]
        magic = 0000000000bab10c
        version = 5000
        txg = 1810474
        guid_sum = 7585982447284902646
        timestamp = 1661353462 UTC = Wed Aug 24 15:04:22 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[11]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803595
        guid_sum = 7585982447284902646
        timestamp = 1659984611 UTC = Mon Aug  8 18:50:11 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[12]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803628
        guid_sum = 7585982447284902646
        timestamp = 1659984780 UTC = Mon Aug  8 18:53:00 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[13]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803629
        guid_sum = 7585982447284902646
        timestamp = 1659984785 UTC = Mon Aug  8 18:53:05 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[14]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803630
        guid_sum = 7585982447284902646
        timestamp = 1659984790 UTC = Mon Aug  8 18:53:10 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[15]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803631
        guid_sum = 7585982447284902646
        timestamp = 1659984795 UTC = Mon Aug  8 18:53:15 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[16]
        magic = 0000000000bab10c
        version = 5000
        txg = 1801040
        guid_sum = 7585982447284902646
        timestamp = 1659971529 UTC = Mon Aug  8 15:12:09 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[17]
        magic = 0000000000bab10c
        version = 5000
        txg = 1769745
        guid_sum = 7585982447284902646
        timestamp = 1659811299 UTC = Sat Aug  6 18:41:39 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[18]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803634
        guid_sum = 7585982447284902646
        timestamp = 1659984811 UTC = Mon Aug  8 18:53:31 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[19]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803635
        guid_sum = 7585982447284902646
        timestamp = 1659984816 UTC = Mon Aug  8 18:53:36 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[20]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803636
        guid_sum = 7585982447284902646
        timestamp = 1659984821 UTC = Mon Aug  8 18:53:41 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[21]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803637
        guid_sum = 7585982447284902646
        timestamp = 1659984826 UTC = Mon Aug  8 18:53:46 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[22]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803638
        guid_sum = 7585982447284902646
        timestamp = 1659984831 UTC = Mon Aug  8 18:53:51 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[23]
        magic = 0000000000bab10c
        version = 5000
        txg = 1801175
        guid_sum = 7585982447284902646
        timestamp = 1659972220 UTC = Mon Aug  8 15:23:40 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[24]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803640
        guid_sum = 7585982447284902646
        timestamp = 1659984841 UTC = Mon Aug  8 18:54:01 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[25]
        magic = 0000000000bab10c
        version = 5000
        txg = 1733305
        guid_sum = 7585982447284902646
        timestamp = 1659624726 UTC = Thu Aug  4 14:52:06 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[26]
        magic = 0000000000bab10c
        version = 5000
        txg = 1768890
        guid_sum = 7585982447284902646
        timestamp = 1659806921 UTC = Sat Aug  6 17:28:41 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[27]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803707
        guid_sum = 7585982447284902646
        timestamp = 1659985184 UTC = Mon Aug  8 18:59:44 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[28]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803644
        guid_sum = 7585982447284902646
        timestamp = 1659984862 UTC = Mon Aug  8 18:54:22 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[29]
        magic = 0000000000bab10c
        version = 5000
        txg = 1803645
        guid_sum = 7585982447284902646
        timestamp = 1659984867 UTC = Mon Aug  8 18:54:27 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[30]
        magic = 0000000000bab10c
        version = 5000
        txg = 1810494
        guid_sum = 7585982447284902646
        timestamp = 1661353553 UTC = Wed Aug 24 15:05:53 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
    Uberblock[31]
        magic = 0000000000bab10c
        version = 5000
        txg = 1810495
        guid_sum = 7585982447284902646
        timestamp = 1661353558 UTC = Wed Aug 24 15:05:58 2022
        mmp_magic = 00000000a11cea11
        mmp_delay = 0
        mmp_valid = 0
        checkpoint_txg = 0
        labels = 0 1 2 3
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:

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?
 
Viimeksi muokattu:
Ilmeisesti riittää että:
(autoexpand on poolissa valmiiksi päällä)
1) Partedilla mklabel GPT uudelle levylle
2) Varmuuden vuoksi vielä scrub
Täysin turhia steppejä.

Sun tarvii tehdä vain nämä komennot:
Bash:
# Viimeeksi korjasin näillä
sudo zpool offline hddpool ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7PU8HFK
sudo zpool replace hddpool ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7PU8HFK ata-SATA_ST4000VN008-XXXXXXXXXXX
 
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!

Edit: ja hyvinhän se meni!
 
Viimeksi muokattu:
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
 
Viimeksi muokattu:
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.
 
Viimeksi muokattu:
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...
 

Statistiikka

Viestiketjuista
261 569
Viestejä
4 540 474
Jäsenet
74 823
Uusin jäsen
MaxMonLar

Hinta.fi

Back
Ylös Bottom