Könnyebb lesz telepítéskor Ubuntu desktopon a root fájlrendszert ZFS-re formázni

 ( trey | 2019. október 7., hétfő - 9:07 )

Pénteken beolvasztásra került a kísérleti (állapotú) ZFS root fájlrendszer telepítési támogatás az Ubuntu desktop "Ubiquity" telepítőjébe. Ezzel egyszerűbbé válik az Ubuntu desktop felhasználók számára, telepítéskor a guided particionálási metódust használva, a root fájlrendszert ZFS-re formázni, majd a rendszert e fájlrendszerre telepíteni.

Részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Jó lesz ez? Mármint desktop alá zfs root?

Miért ne ? Ha memória van a gépben nincs gond. Évek óta használom desktop gépen, többször húzott ki a bajból. Március óta tudja a TRIM-et is, úgyhogy már az SSD-ért sem kell aggódni.

Én elismerem, hogy egy nagyon faja fájlrendszer, de pl egy BTRFS tudása pont elég lenne Desktophoz, majdnem mindent tud, amit a ZFS, desktophoz elég az offline dedup, pöttyedt szelídebb az erőforrásokkal. Vagy a BTRFS még mindig kevésbés stabil egy ZFS-hez képest?

Nem ismerem az aktuális állapotát, mert nem használom jelenleg. Én úgy gondolom, hogy ha fejlődik is, azt csak csiga tempóban teszi. Márpedig lenne hová fejlődnie. Szerintem fél úton van a hagyományos fájl rendszerek és a zfs között.
Viszont azt el kell ismerni, hogy pl. a Synology az összes NAS-ára ezt teszi, ezért aztán annyira nem lehet rossz. Persze nem tudjuk, hogy mennyi benne a saját fejlesztés.
Amúgy nem mindegy milyen célra használod a géped. Nyilván egy otthoni bohóckodó gépre nem kell zfs. Én viszont munkára használom, nekem bőven megéri azt a kevés plusz erőforrást.

A Synology nem "rendesen" használja a BTRFS-t, hanem a mapper-en és a dmraid-en keresztül.
Pont az veszik el, ami a legfontosabb lenne egy NAS-on, a natív RAID...
A Synology úgy bővíti a kötetet, hogy felhúz mellé a mapper-rel egy újat és összefűzi. Nagyon gáz.

Egyébként a BTRFS fejlesztése eléggé leállt, ha végignézitek a fórumot, nagyon lehangoló a kép.

A ZFS meg simán elveszít minden adatot, ha kivesz az ember a MIRROR egyik elemét, IO error-ra hivatkozva. Már kétszer jártam így....
---
http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

Hogyan veted ki a tükörből a lemezt, remove-al? Milyen os és ZFS verzió volt? Azért érdekes amit írsz, mert nekem még FAULTED állapotú pool-ból is olvasott vissza adatokat, ami elvileg totál hibás.

Ez engem is érdekelne, mert én is azt tapasztaltam, hogy elég nehéz kinyírni.
Pedig tesztelés közben adtam neki rendesen.

Nemrég írta egy RedHat fejlesztő, hogy azért dobta a RedHat a BTRFS támogatást, mert röviden a BTRFS egy szar. Hosszaban is kifejtette, nem vagyok fejlesztő, amit értettem belőle az annyi volt, hogy túl gyorsan akartak belefejleszetni túl sok funkciót és kód minőség ellenőrzésére nem fordítottak figyelmet. Nagyon bug-os a kód, és már akkora, hogy a RedHat szerint csak a teljes kód újraírásával lehetnem megoldani, amivel ők nem fognak küzdeni. Ezért nem támogatják. Ez elég rosszul hangzik.

Erre az írásra van egy linked? Amit találtam, az mind 2017-es hír, cikk.

Igen, ezeket én is megtaláltam. Azért köszi.

elvileg a BTRFS még mindig nem production ready... bár én sok éve használom a home szerveren és laptopon, sőt céges QA szerveren is, soha semmi bajom nem volt vele... régen néha megtörtént, hogy le kellett futtatni egy offline btrfs check-et, de mostanában nincs ilyen.

Pedig használva van rendesen: a szerveren backupnak használom, jelenleg van 500+ subvolume a 4x1TB raid1-es filerendszeren, a laptopon is kb. ugyanannyi (5 percenként, naponta, havonta snapshotolok).

Nekem személy szerint sokkal jobban tetszik, mint a zfs, ilyenek miatt mint a "cp --reflink=always" vagy a subvolume-ok "szabadsága": zfs-nél ilyen egyszerű dolgot nem lehet megcsinálni, hogy egy dataset-et "megklónozok" és mindkettő szabadon él tovább, azt törlöm le és olyan sorrendben, amelyiket csak akarom. Nyilván, más az elképzelés, ami a snapshotokat illeti.

Idézet:
elvileg a BTRFS még mindig nem production ready...

Süsü (ahol évek óta alapértelmezett FS mind a nyíltSÜSÜ mind a SLES/SLED-en a /-re, home-ra pedig xfs) kedveli ezt :)

Szvsz. az nem tett jót a megítélésének, hogy az RH (érdekes módon miután egy csomó időt ölt az xfs fejlesztésébe, akkortájt, amikor az Oracle-el elkezdett vitatkozni, egyszerre azzal, hogy a Süsü bejelentette a btrfs defaultot) bejelentette, hogy unsupported...

Az itthoni gépemben van egy öt-hat éves btrfs fájlrendszer, ami indult egy 1T-s lemezről, aztán egy darabig pakoltam bele a diskeket, aztán az egész mókát áttettem egy 4T-sre, aztán leszedtem róla csomó szemetet és vissza egy most éppen 1T-s laptop vinyóra, közben volt, hogy RAID1-re tettem, aztán mégsem, volt disk hiba (szépen felsorolta a hibás fájlokat, kuka, ment az élet tovább másik lemezről)... mindezt úgy, hogy a fájlrendszer végig fel volt csatolva és csak annyi downtime volt, amíg a disk cserék miatt ki volt kapcsolva a gép :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem tartozik szorosan a tárgyhoz, de azt látom a több éves laptopomon, hogy az újabb és újabb linux verziók is szépen lassulnak, kb. úgy, mint a windows verziók. Bár hozzáteszem, a Windows 10 sokkal reszponzívabb, mint az Ubuntu... régen ez nem így volt.
Ez mind szubjektív észrevétel, de nekem ez sokkal fontosabb, mint mindenféle méröszámok, amik ennek az ellenkezöjét bizonyítják.

Be kell látni, elblótosodott a linux világ is tisztességesen, hála a sok innovációnak.

--
robyboy

Formázz ext2-re, az jó lesz!

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

A Pöttering féle bloat infrastruktúrán az sem segít.

--
robyboy

Bármikor írhatsz sajátot, akár Windows XP-re is!

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Hogy ez nem jutott eddig az eszembe!

--
robyboy

Biztos, hogy a fájlrendszer miatt lassú? Szerintem egy XFCE vagy LXDE használat nagyobb performancia növekedést eredményez, mint ext4 helyett az ext2.

Ez egyébként igaz.

--
robyboy

sőt, nem csak hogy lassúbb, de "I believe the 2.6 kernel is slowly getting buggier..." :)