OpenZFS 2.0.0-rc2

Tesztelhető az OpenZFS 2.0.0 második kiadásra jelölt verziója. Támogatott platformok:

  • Linux 3.10 - 5.8 kernelek
  • FreeBSD 12.1 (release), stable/12 és HEAD (13)

Változások:

  • vdev_ashift should only be set once #10932
  • libzfs: Don't leak buf if nvlist is too large #10882
  • pool may become suspended during device expansion #10897
  • zdb leak detection fails with in-progress device removal #10920
  • FreeBSD: Do not copy vp into f_data for DTYPE_VNODE files #10929
  • Need a long hold in zpl_mount_impl #10936
  • libzfsbootenv: lzbe_nvlist_set needs to store bootenv version VB_NVLIST #10937
  • Rename acltype=posixacl to acltype=posix #10918
  • cmd/zgenhostid: replace with simple c implementation #10887 #10925
  • Fix stack frame size: dnode_dirty_l1range() #10879
  • dmu_redact_snap: fix possible memleak #10879
  • Fix stack frame size: dmu_redact_snap() #10879
  • Fix stack frame size: spa_livelist_delete_cb() #10879
  • zpoolprops.8: fix raidz par[i]ty typo #10923
  • zfs label bootenv should store data as nvlist #10774
  • Linux: Prevent destruction while showing mount devname #10892 #10927
  • config/zfs-build.m4: never define _initramfs in RPM_DEFINE_UTIL #10898
  • libzutil depends on libnvpair #10915
  • FreeBSD: convert teardown inactive lock to a read-mostly sleepable lock #10896
  • Force the use of '.' as decimal separator. #10878
  • Initialize mmp_last_write when the mmp thread starts #10873
  • FreeBSD: drop dependency on cryptodev module #10901
  • Introduce ZFS module parameter l2arc_mfuonly #10710
  • Avoid possibility of division by zero #10894
  • dnode_special_open() error: unchecked function return 'zrl_tryenter' #10876
  • Add a missing option prefix - in zfs-tests.sh usage() #10893
  • Display pbkdf2iters property as plain number #10871
  • libshare: Add missing headers for nfs.c #10880
  • FreeBSD: reduce priority of ZIO_TASKQ_ISSUE writes by a larger value #10872
  • Spruce up pkg-config files for libzfs/libzfs_core #10869
  • man: Cross-reference zfs-load-key(8) for ENCRYPTION mention #10866
  • man: Add zfs rename -r to zfs-rename(8) SYNOPSIS #10866
  • Sequential scrub and resilver updated comments
  • Avoid posting duplicate zpool events #10861
  • nowait synctask must succeed #10855
  • Retain thread name when resuming a zthr #10881
  • Fixes for running FreeBSD buildworld on Linux/macOS hosts #10863
  • Replace cv_{timed}wait_sig with cv_{timed}wait_idle where appropriate #10843
  • Links in Source Files #10859
  • zvol: unsigned off can not be less than zero #10867
  • Fix -Werror,-Wmacro-redefined in limits.h #10864
  • Make spa_stats.c tunables visible on FreeBSD #10858
  • FreeBSD: Fix up after spa_stats.c move #10860
  • Add 'zfs rename -u' to rename without remounting #10839
  • FreeBSD: Remove unused SECLABEL code #10847
  • libspl: Provide platform-specific zone implementations #10851
  • FreeBSD: Simplify INGLOBALZONE #10851
  • FreeBSD: Define crgetzoneid appropriately #10851
  • zio_ereport_post() and zio_ereport_start() return values are ignored #10857
  • Typo Correction #10850
  • Move spa_stats.c to common code #10842
  • FreeBSD: Fix spurious failure in zvol_geom_open #10841
  • FreeBSD: add support for KSTAT_TYPE_RAW #10836
  • Linux 5.9 compat: NR_SLAB_RECLAIMABLE #10834
  • Fix another dependency loop #10356 #10388
  • Fix a dependency loop #10388
  • config/zfs-build.m4: add --with-vendor flag #10385
  • Fix definition of BLKGETSIZE64 on FreeBSD #10818
  • module/zstd: pass -U__BMI__ #10758 #10829
  • Add the Xr's to the SEE ALSO as well #10589
  • dnode_sync is careless with range tree #10708 #10823
  • Fix NEWS file #10824
  • zpool: Change base URL for ZFS messages to openzfs-docs #10820
  • Remove duplicate dnode.h include #10816 #10819
  • Always track temporary fses and snapshots for accounting #10791
  • Remove pragma ident lines #10810
  • FreeBSD: disable neon usage #10809
  • Introduce limit on size of L2ARC headers #10765

Letölthető a projekt GitHub oldaláról

Hozzászólások

Szerkesztve: 2020. 09. 20., v – 14:28

ZFS biztos nagyon kiforrott, de ami miatt ejtettem, az az, hogy nem tud uneven diszkekbol raid tombot epiteni.

Ugye otthoni low-budget raid ugy epul, hogy veszek egy nagy, eppen legjobb ar/kapacitas aranyu vinyot, es hozzaadom a tombhoz.

Amikor egy vinyo szejjelmegy, azt kiszedem es odaadom a gyerekeknek jatszani.

Erre a fajta workload-ra a zfs hasznalhatatlan. A sima mdraid egesz jol szuperal:
- egy raid5 akkora, mint a legkisebb vinyo;
- egy raid1, ami a nagyobb vinyok vegen a maradekot lefedi, egyfajta 'scratch' particiokent.

Pl. most van egy 3, egy 4 es egy 6TB-os vinyo a szerverben. Ezen van egy 3TB-os raid5 (szumma 6TB kapacitassal). A 4TB-ost hagytam, mert a pici 3TB-os mar majdnem 5 eves es lassan cserelve lesz, ergo a 4TB-os rovidesen a legkisebb vinyo lesz, teljes kihasznaltsaggal. A 6TB-oson szinten kihagytam 1TB-ot ugyanezert, a vegen pedig most van egy 2TB-os raid1, downgrade-elt uzemmodban, aztan amikor a 3TB-osbol 6-8 lesz, akkor lesz parja is.

Ezzek a setupnak az elonye, hogy koltsege teljesen minimalis, par evente egy atlag vinyo, es teljesen jol szuperal. Es legfokepp: mivel mindegyik vinyo teljesen, totalisan masmilyen, nem gond a raid5 reconstruct, a kieses eselye nem komoly.
 

Erre a workload-ra a btrfs amugy tokeletes lenne, mert az kepes arra, hogy pl. raid1-nel uneven particiokat is hasznaljon; egyszeruen ugy oldjak meg, hogy minden blokkot ket vinyora ir ki, de btrfs-nek tokmindegy, hogy melyikre. Csak epp alapos utanaolvasas utan azt latom, hogy bizony meg mindig erosen reszelgetik (lasd btrfs levlistan epp most volt egy 'utolso durva bugok' osszefoglalo); kb. az ubuntu 22.04 LTS-re mar jo lesz. A CoW miatti veszteseg elegge fajo (kikapcsolva meg elveszik a btrfs osszes elonye, nice job guys), de a media server workload-ra nincs nagyon utban.

(bocs a hosszu agymenesert, de mostansag sokat olvasgattam btrfs/zfs miatt a temaban, gondoltam, osszefoglalom, hatha valakinek hasznos)

Régen játszottam vele FreeBSD-vel, de akkor is lehetett már nem csak egész lemezt, hanem partíciót is adni neki. Sőt! Javasolták, ha egyforma kapacitasú, de eltérő gyártótól való lemezeket használsz, akkor ugye nem pontosan egyforma bájtra a kapacitás. Erre volt megoldás, hogy mindegyiken a lehető legnagyobb méretű, de egyforma méretű partíció létrehozása és abból felépíteni a pool-t. Nyilván egyiken-másikon marad kihasználatlan hely, de elhanyagolható. Vagy a másik ok, ha elpusztul egy lemez és nem kapsz ugyanakkora méretűt, arra is megoldás.

Ha meg nem azonos kapacitásúak a lemezek, akkor meg van autoexpand. Ha engedélyezed a pool-ra, és menet közben kicserélgeted alatta az eszközöket, amint minden eszközön elérhető annyi hely, automatikusan nő a pool kapacitás.

Az meg hogy a nagyobb kapacitású lemezen, a maradék helyen másik pool-t/tömböt hozol létre, szerintem nem sok értelme van.

Nagyon is sok. Tfh van egy ZFS mirror, amit migrálni akarsz RAIDz2 -re úgy, hogy még két diszket beleteszel. Ekkor csinálsz 2 db sparse filet, akkorát mint a diszkek. Ezekkel a fileokkal + a 2 új diszkkel megcsinálod a raidz2 tömböt, ejecteled a 2 sparse filet. Ezután migrálod az adatokat a mirrorról, átrakod az egyik diszket a mirrorból a raidz2 tömbbe, resilvert megvárod, utána törlöd a mirrort, és a felszabaduló diszket is betolod a raidz2-be, resilvert megvárod.

Nem kötekszem tényleg kérdezem. Csináltál már ilyet? Hová rakod a 2 fájlt, ahhoz kell még két disk, hogy elférjen vagy egy dupla méretű. Vagy kisebbre csinálod a raidz-t és utána növeled a méretét?

Azért kérdezem, mert lassan lesz egy ilyen melóm és még nem találtam ki, hogy csináljam.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

ha jol ertem az sparse fajl, az csak azert kell hogy a raidet megtudd csinalni. utana kidobod, igy "fellabu" lesz a zfs, atmasolod az adatokat, majd a regi diskeket betolod a zfs-be. (nyilvan ket lepessel, ha nincs eleg hely)

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

# zpool create foo raidz loop43 loop42 loop26
invalid vdev specification
use '-f' to override the following errors:
raidz contains devices of different sizes

# zpool create foo raidz loop43 loop42 loop26 -f

# zpool status
  pool: foo
 state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    foo         ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        loop43  ONLINE       0     0     0
        loop42  ONLINE       0     0     0
        loop26  ONLINE       0     0     0

errors: No known data errors

 

 

# zpool list -v root
NAME                              SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
root                              920G   629G   291G        -         -    17%    68%  1.00x  ONLINE  /mnt
  diskid/DISK-STF605MS1NJUMKs1d   920G   629G   291G        -         -    17%    68%
log                                  -      -      -         -      -      -
  diskid/DISK-0214201400176p1    3,97G   344K  3,97G        -         -     0%     0%
cache                                -      -      -         -      -      -
  diskid/DISK-0214201400176p2    25,8G    33K  25,8G        -         -     0%     0%
#

Itt a pool 2 diszkből áll, mind a kettő partícionálva van, és ezek vannak betéve különböző funkcióval. Az értelmét nem kell kérdezni, játékból lett így megcsinálva.

Nekem erre a felvetésre az jutott elsőre eszembe, hogy a ZFS-sel foglalkozó netes problémafelvetések 85%-a oda vezethető vissza, hogy mindenféle "gyári" (fejlesztői) ajánlást figylmen kívül hagyva összehánynak valamit (HW és SW terén egyaránt, jellemzően otthon), aztán csodálkoznak, hogy nem működik, hibázik, összeomlik.

Tehát a fenti mondat alapján visszakérdeznék: melyik enterprise HW vagy SW lemezkezelő rendszer teszi ezt lehetővé így, ahogy Te leírtad, hogy szeretnéd?
Szerintem egyik sem. A nagyobb lemezek plusz kapacitása mindig elveszik. A ZFS sem azért jött létre, hogy ami otthon a fiókban (a kuka helyett) összegyűlt az évek alatt, azt el lehessen valamire használni, ráadásul megbízhatóan...

Javaslom, hogy olvasgass Ceph-ről szóló írásokat, ott sok helyen nagyon jól leírják, miért nem szerencsés különbőző méretű meghajtókat használni egy rendszerben(kötetben. Adat- és terhelés-elosztási problémákat is felvet a dolog szép számmal.

A másik megközelítésem: ha szerenék egy redundáns tömböt, akkor veszek annyi dikszek, amennyi kell hozzá, és megcsinálom. Amikor ennek lejár a megbízhatósági ideje (garancia, stb. ki miben hisz), akkor kicserélem mindet. Ha épp nagyobb a jó vétel, akkor kapásból több helyem is lesz a csere után. Ha idő közben megromlik egy elem, akkor kicserélem egy akkora vagy nagyobb egységre, és megy tovább minden (ha nagyobb, akkor elveszett a plusz). Ha a tömb még "szavatos", de kevés a hely, akkor vagy csinálok egy újabb tömböt, vagy kicserélem az összes diszket nagyobbra (mert kell a hely).

Én sehogyan sem tudom értelmezni, hogy veszek egyesével különböző diszkeket valamire, aztán egyszer csak redundanciára vágyom a meglévő anyag felhasználásával, de 100%-os kapacitás hasznosítással, úgy, hogy az előzmények alapján semmiféle tervezés nem előzte meg a megvalósítást. És ezt egy tároláskezelő rendszer hibájának felróni...

Hát, egy enterprise eszköz (mint amilyen a ZFS is, pl.) olyan környezetbe lett tervezve, olyan feltételekre. Ha valaki máshol akarja használni, akkor természetesen megteheti, de vagy biztosítja az enterprise feltételeket, vagy együtt él a problémákkal, ami ezek hiányából fakadnak. És erről nem az adott rendszer tehet, ez nem hiányosság/hiba.

Szóval szerintem releváns ezen kifejezések felemlegetése jelen esetben is, mert a ZFS nem kérdezi telepítéskor, hogy home vagy enterprise use case lesz, és annak függvényében vagy tud mindent IS (szegény az otthoni user, így különböző diszkekkel, 100% kapacitás kihasználással, megfelelő redundancia mellett megy megbízhatóan), vagy korlátai lesznek (fizessen a cég, van miből, így különböző diszkek esetében a legkisebb határozza meg a méretet, a többi kapacitás bukó).

Egyébként szerintem ebből nagyon messzire menő vitát is lehetne kreálni (de nem szeretnék), mert nekem elsősorban azért nem tetszik az ilyen, mert ha otthon így-úgy sikerül összetákolni, akkor jön a "működik ez, nem kell drágább-jobb céghez sem, mindenki csak le akar húzni, eladom másnak így ahogy van, olcsón", és máris fordul a kocka. Vagy a másik oldalról nézve, aki rendes rendszert akar csinálni az ügyfeleknek, az igényes annyira a munkájára, hogy otthon, privát felhasználásra is rendesen csinálja meg, nem összetákolja. Abból legalább tanul. Ráadásul pont diszkekről beszélünk, amiből mindig lehetett olcsón venni még itthon, Forint alapon is, sokat.

De mondok akkor consumer grade cuccra épülő tárolós példát: olvasgasson Backblaze blogot. Ott minden sima bolti, nem üzleti célra szánt. Mégis 60 db egyforma lemez egy storage pod és 20 db tök egyforma storage pod egy vault. Pedig biztosan nekik is egyszerűbb lenne ha akármit bedobálhatnának a dobozokba ami épp a legolcsóbb.

De ha már így alakult, akkor engem érdekelne, hogy mi vezérel, hogy a tákolás védelmére kelj? Persze én is szoktam próbálkozni, ilyen-olyan "nem szép" megoldásokat kipróbálni itthon. Nem arról van szó, hogy én lennék a "csak az ajánlás szerint mindet, pénz nem számít" elv földi helytartója. Csak érdekel, hogy miért fontos az, hogy senki sem mondja ki, hogy ne tákolj, nem lesz jó?

> egy enterprise eszköz (mint amilyen a ZFS is, pl.) olyan környezetbe lett tervezve

Nem tudom, mit jelent az enterprise kifejezes a openzfs eseteben, azt viszont igen, h mukodik osszetaknyolt kornyezetben, vagy epp szereny korulmenyek kozott is.

Abban sem vagyok biztos, h cel-e v. cel volt-e valaha az enterprise az openzfs eseten.

 

> erről nem az adott rendszer tehet, ez nem hiányosság/hiba

Ez igy meg egy bazi nagy bullshit. Minden masra, a nem enterprise-ra is ra lehet mondani.

 

> korlátai lesznek

Mint ravilagitottak tobben a topicban, az emlitett korlat nem letezik. Lehet particiokat hasznalni, mint pl. az md raid.

Ha ugy nezem, epp a zfs az, ami tud mindent *IS* (ahogy te irtad). De nem erzem, h ettol meg home usereknek szantak volna...

 

> Ráadásul pont diszkekről beszélünk, amiből mindig lehetett olcsón venni még itthon,

Nem lehet, h az erdemi kulonbseget akkor nem is a zfs, hanem a HW minosege fogja meghatarozni nagyreszt?

Nekem ugy tunik, hogy nem az szamit, h pl. lvm+md+ext4+akarmi+megvmi vs. (open)zfs, hanem az, hogy mit es hogyan rak ossze.

 

> mi vezérel, hogy a tákolás védelmére kelj

Te vagy a masodik, aki azt allitja, hogy a takolas vedelmere kelek.

Mar a kifejezest sem ertem. Vedelemre szorul vagy wtf?

 

> miért fontos az, hogy senki sem mondja ki, hogy ne tákolj, nem lesz jó

Akkor szogezzuk le, hogy ilyet nem irtam, meg hasonlot sem. Olyat tulajdonitasz nekem, amit en nem irtam.

Utana, ha szukseges, beszelhetunk arrol, hogy takolni jo v. rossz v. hogyan vagy mi a helyzet, kinek mi a velemenye.

 

t

> ertelme

azt csak te tudhatod

 

> teljesitmeny

nem latom az osszefuggest

 

> disk vege

Ha csak ez kell, megvalaszolta mas, hasznalj particiot.

ZFS manual-ok egyontetuen allitjak, hogy egy fizikai diszk ket kulon zfs pool-ba sose keruljon. A reszletekre nem emlekszem, de nagyon eros javaslat volt. :)

 

lasd pl. az elso google talalatot: https://superuser.com/questions/1199316/zfs-on-multiple-partitions-on-o…

 

ZFS is seek-heavy to begin with, because of its copy-on-write design. (This is exacerbated if you use snapshots. Snapshots happen to be a ZFS feature that lots of people really like, even if they don't really use any of ZFS' other features, but they come at a significant cost in terms of risk of data fragmentation, particularly if you make many small writes.)

When you add additional storage to an existing pool, which you would with your proposed scheme, the data already stored is not automatically rebalanced. Instead, ZFS writes new data blocks to vdevs that have the most free space, which causes the data to be distributed across all vdevs over time as it is written. In your case, this means that data will be distributed roughly as you expect: newly written data, including changes to existing files, is more likely to be written to the newly added vdev than to the previously existing vdev(s). Since all vdevs are on the same physical disk, there is no real reliability gain from this; if the single disk dies, then your pool dies, and takes all your data with it.

El kéne dönteni, hogy otthon akarjuk, hogy a Táncoló_talpak.mkv -nak / nyaralási képeknek legyen hely ZFS-en, olcsón, meglévő eszközökből, vagy csillió IOPS-es rendszert akarunk építeni.

Az első felhasználásra, ha nem kukakategóriás a HDD, semmi baja nem lesz a partíciók miatt(*). Ha sok random írás/olvasás van (pl. fordítás, fejlesztés, VM-ek), akkor egyébként otthonra is inkább bedobnék egy 1-2TB-s SSD-t, amit lehet naponta snapshotolni a HDD-kre, hogy legyen backup.

 

(*) Azért backup legyen... 

 

Szerk: A superuser.com-os link arra vonatkozott, hogy akart egy olyan drive-ot, ami Windowsból meg Linuxból is elérhető. 2017-ben ez még csak úgy működött, ahogy csinálta. De 2020-ban Jörgen Lundman jóvoltából (https://openzfsonwindows.org/), akinek az OSX portot is jórészt köszönhetjük, már közel járunk ahhoz, hogy végre a ZFS legyen az első modern fájlrendszer, ami minden desktop platformon működik, és könnyű átjárást biztosít.