- 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.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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)
- A hozzászóláshoz be kell jelentkezni
Ezt az "uneven" dolgot kifejtenéd? Arra gondolsz, hogy nem egyforma méretű lemezekből/partíciókból?
- A hozzászóláshoz be kell jelentkezni
igen.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Szerintem ZFS is tud particiókat használni eszközként, ha akarod. Legalábbis én tuti használtam így.
- A hozzászóláshoz be kell jelentkezni
Szia
Én így használom, pont azért mert egyre nőnek a HDD méretek és csere esetén könnyebb a raid-eket cserélni.
Arra vigyázok csak, hogy egy raid-be egy HDD egyszer kerüljön be. És a másik partíció másikba kerüljön.
- A hozzászóláshoz be kell jelentkezni
Van erről használható leírás? Eddig mindenhol azt olvastam hogy a ZFS-nek a teljes lemez kell.
- A hozzászóláshoz be kell jelentkezni
Semmiben nem tér el a dolog, csak nem /dev/ada0, hanem /dev/ada0p1 (Linuxul: sda helyett sda2-t adsz neki oda).
- A hozzászóláshoz be kell jelentkezni
Sőt a ZFS fájlt is tud használni egy pool-ban, az már más kérdés, hogy ennek mi az értelme.
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Én még úgy tanultam, hogy az sdX az ördög játékszere, és inkább a diszk szériaszáma alapján létrejött deviceokat használjuk, mert az akkor is működni fog, ha más sorrendben dugjuk be az eszközöket. :)
- A hozzászóláshoz be kell jelentkezni
Vagy esetleg egy másik gépbe rakjuk, disaster recovery miatt. Jogos.
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.
- A hozzászóláshoz be kell jelentkezni
fixme, de mikor letrehozod akkor ugyis fix neven van, utana meg a block deviceken signatura alapjan keresi meg ki hova tartozik, lehet akar dev/csigabiga es dev/batkamano a nevuk
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
# 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
- A hozzászóláshoz be kell jelentkezni
ertem, hogy force, de van-e ertelme? teljesitmenye? ki tudod-e hasznalni az eltero meretu diszkek vegen marado slack-et?
- A hozzászóláshoz be kell jelentkezni
# 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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Leirta, h otthon taknyol ossze, abbol amibol tud.
Miert peldalozol az Enterprise es a Ceph szavakkal?
- A hozzászóláshoz be kell jelentkezni
Miért sértődsz meg folyton, amikor valaki a tákolgatásra azt találja mondani, hogy tákolgatás?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem sertodok. A jelen kontextusban meg a felvetesednek sem latom az ertelmet (ld. "taknyolas").
Viszont azt latom, h megint jottel kotekedni. Mazel tov.
- A hozzászóláshoz be kell jelentkezni
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ó?
- A hozzászóláshoz be kell jelentkezni
> 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
- A hozzászóláshoz be kell jelentkezni
> ertelme
azt csak te tudhatod
> teljesitmeny
nem latom az osszefuggest
> disk vege
Ha csak ez kell, megvalaszolta mas, hasznalj particiot.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ja.
Mi a kerdes?
- A hozzászóláshoz be kell jelentkezni
Mint ahogy azt is, hogy különböző méretű és teljesítményű lemezek se legyenek. De hát szegény IT-s szarik a manual-ra.
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.
- A hozzászóláshoz be kell jelentkezni
A kulonbozo teljesitmenyu drive-okat dedikaltan tamogatja.
Nem emlekszem a feature nevere, de arrol szol, h ha van egy ssd es egy hdd, akkor az ssd-rol olvas inkabb.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni