A Fedora alapértelmezetté tenné a btrfs-t desktopon; tesztnapot hirdettek

Matthew Miller, a Fedora projekt vezetője a Twitteren jelezte, hogy segítség kellene a btrfs teszteléshez, mert azt alapértelmezetté kívánják tenni desktopon a Fedora 33-ban. Részletek itt. A tesztelés részleteiről a Test_Day:F33_btrfs_by_default_2020-07-08 wikioldal ad felvilágosítást.

Hozzászólások

Ismereteim szerint csak a btrfs és a zfs elég fejlett ahhoz, hogy komolyabb dolgokra lehessen használni. A RedHat megpróbálta fejleszteni a VolumeGroup vonalat, de valószínű rájött, hogy nincs hova fejleszteni. A zfs pedig licencben problémás. Tehát az egyetlen problémamentes FS, amit nem kell nulláról lefejleszteni az a btrfs.

Ez a bejelentés azért is meglepő, mert centos8-ban alap repóban nincs benne a btrfs-tools (RHEL gondolom ugyanaz), tehát nem csak sunyizni akartak valamiért amikor bejelentették, hogy teljesen kihátráltak a btrfs mögül, hanem komolyan is gondolták.

Rolling-release distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL.

Vagyis per pill a fejlesztések ütemezése: Fedora -> CentOS Stream -> RHEL/CentOS. Ezzel elérték azt, amit te is akartál fentebb, hogy a community teszteljen, de megtartották azt, hogy a Fedora mindig cutting edge legyen, a RHEL/CentOS pedig megkapja a teljes körű RH-féle QA folyamatot. Az eredeti feltevésedre ("Attól még lehet, hogy a CentOS-ben mondjuk default fájlrendszer, míg a RHEL-ben egy "technology preview" javaslat. Nem? De."): lehetne, csak semmi értelme nem lenne egy ilyen húzásnak, mert a CentOS elvesztené a felhasználói bázisának egy részét (mert kiesik a rendszerből az a QA, amit az RH a RHEL-be beletesz), ami hosszabb távon a RHEL-nek rossz lenne (pl. a CentOS userek váltanak Oracle linuxra, akkor tőlük fognak supportot venni). És azért egy ilyen esetben nem csak annyi a váltás, hogy az fstab-ban átírjuk, Süsüék három openSUSE release-t csináltak végig, mire bevitték a SLES/SLED ágba.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Te mit tennél? Hagynád, hogy használjanak ingyen egy Ubuntu-t vagy pláne Debian-t? :)

Ha adnak ingyen, support nélkül RHEL-t CentOS néven, akkor nyilván ezt fogod használni, ha amúgy nincs bajod a RHEL kapcsán a disztribúcióval. Enni sokat nem kér a Red Hat oldalán, viszont könnyedén konvertálható az ügyfél a RHEL felé, ha support igénye keletkezik.

A másik irány az, hogy az éles üzem RHEL, a többi meg CentOS, ott nyilván a Red Hat is tudja, hogy nem fogják megvenni a fejlesztői környezetekre a RHEL-t, ha ad egy CentOS-t, akkor viszont nem fognak más disztribúció felé kacsintani.

Mióta összebarátkoztak a RHEL-el, vannak ilyen feature tesztelős ágaik (https://www.centos.org/centos-stream/), de persze meg van még a klasszikus RHEL-forrásból forgatott történet is.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Érdekes, hogy a ZFS-t csak néhány disztribúció látja licencileg problémásnak. A Canonical az Ubuntuval és a Debian alapú Proxmox például köszöni szépen jól el van vele.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

"ahhoz, hogy komolyabb dolgokra lehessen használni."

A vicc az, hogy manapsag a komolyabb dolgok el vannak egyszeru, de gyors fs -el.
Es megvannak mindenfele lvm nelukul ....

btrfs meg minidg sokkal lassabb, mint egy egyszeru xfs vagy ext4.

Mit nevezzel komolyabb dolognak ? ;-)

Volt egy par ujitas block layerben is , de
nem azt latom, hogy mindenki ra mozdult volna az uj feature-okre.
plain old simple ..

 

Ami erdekes lenne latni, hogy

overlayfs+xfs vagy btrfs onmagaban jobb e tobb retegu kontenerezeshez.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Pár terület, ahol szerintem csak ez a két FS jöhet szóba:

  • storage - 100 TB, 24 disk, pl nfs használatnál 100 volume, egyenként quotázva, felhasználás függvényében tömörítve/titkosítva/backupolva
  • konténer fs - 1000 konténernél nem mindegy, hogy snapshot-al megy le egy pull, készül el egy új konténer, vagy copy-val, még ha az overlayfs ezen gyorsít is egy fokot, komolyabb környezetkeben teljesítményproblémái lesznek
  • virtualizációs környezetnek háttérfs - snapshotk, klónozások tömkelegének kezelése, backup/tükrözés másik storage-ra

Igen, ezek olyan területek, ahol ez a kettő jön szóba. De ezek nem desktop felhasználási területek, hanem szerver, munkaállomás. Itt meg a hír kapcsán arról volt szó, hogy mennyire jó ötlet ezt rátolni egy desktopban használt Fedorára.

Talán még a snapshot az egyetlen valós érv, amit nagyon átlag felhasználó is kamatoztathatna, nem kéne ilyen Minten behozott Timeshift-szintű komolytalanságot használni, akinek rendszeres backupra van igénye, és nem tud magának megbízható alternatíváról gondoskodni, annak a Btrfs-nek ez a funkciója megváltás lenne.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Háború előtti pörgő mágnes korongokra lehet ext4 jobb, de átlag felhasználásra egy NVMe SSD-re hót mindegy, sőt, bizonyos feladatokra még talán gyorsabb is. Az meg szerintem fapados használatnál sem egy hátrány, hogy hetente pillanatok alatt le tudsz húzni egy inkrementális backupot, illetve esetleges bit rot nem marad észrevétlen.

Mondjuk pár éve még igen mélyeket szoptam házi barkács felhasználásra BTRFS-sel, szóval kritikusabb környezetbe biztosan nem tenném.

Ami miatt a Süsü is váltott: snapshotok. Pl. Süsün a zypper össze van drótozva a snapperrel (ami meg a btrfs-sel és a grubbal), így pl. egy rosszul sikerült upgrade után a GRUB-ból kitudod választani az előző állapotot, és azt bootolod.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Nem tudom, hogy csak szerencsés vagyok-e, de olyat, hogy rosszul sikerült upgrade már nagyon-nagyon rég (talán 15 éve) nem láttam. Viszont a fentebb is említett közepesen erős laptop kategóriában véleményem szerint erőforrás pocsékolás ilyesmiket használni. Sem a tárhely, sem a RAM nem felesleges nálam sem :) Persze azt be kell vallanom, hogy btrfs ezirányú igényeit nem ismerem, a zfs-ről tudom, hogy "éhes".

Nálam se, de nyugodtabban állok neki egy dist-upgrade-nek úgy, hogy tudom, hogy legrosszabb esetben két lefelé nyíl és két enter a "visszaállítás" :) A tárhelynél elenyésző az igénye (a felülírt adatok mindkét verziója meg van, persze, de azon felül minimális), a RAM pedig ZFS-nél is csak dedupnál fontos nagyon (ott a deduphoz használt táblákat szerencsés memóriában tartani, különben egy sima diszk írásból lesz egy csomó random I/O-d hogy megnézze, ki kell-e írni az eredeti kérést lemezre, vagy már meg van valahol), egyébként csak jó jön (ha csak cache-nek van használva).

Süsü-n pl. évek óta default (mind az openSUSE-nál, mind a SLES-nél/SLED-nél), nem vészes (különösen, hogy ügyelnek arra, hogy ahol gond a CoW és/vagy snapshot [mondjuk adatbázisok], ott kapjanak adattehénmentes [nodatacow] subvolume-ot).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

?

Szerk.: asszem meg van, az L2ARC-hoz használt táblákra gondolsz? Valóban, jogos, a deduphoz (tárolt adatmennyiség függvénye) _és_ az L2ARC-hoz (L2ARC device méret függvénye) is kellhet sok memória.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Szerintem desktop disztróba felesleges Btrfs-t alapértelmezetté tenni, arra teljesen kiváló a mostani ext4. Félre ne értsetek, nincs bajom a Btrfs-sel, én is használtam egy ideig, teljes megelégedéssel, megbízható, nem is lassú, anno az online defrag, CoW, röptömörítés miatt használtam még mikor HDD-t használtam, de a snapshot funkciója is nagyon hasznos. De desktop disztróba defaultnak szerintem overkill, átlag felhasználónak nincs szüksége ezekre az extra feature-ökre, amit a Btrfs, ZFS, stb. nyújt. Akinek meg van rá szüksége, annak eddig is nyitva állt a lehetőség, hogy telepítéskor nem a default-ra nyom OK-ot, hanem megváltoztatja saját igény szerint.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Desktopon és alap szervereken én egy kényelmi funkció miatt kezdtem használni btrfs-t, mégpedig a volume-ok miatt. Ext4 időben többször megjártam, hogy a root partíción sok hely volt, míg a home/var/stb betelt. Ezekkel elég sokat szívtam. Ha minden hely egy partícióban van ami volumeokra van osztva, akkor ez a probléma megszűnik.

Ezen túl az átméretezés is kényelmesebbé válik, mert vm esetén diszket növelek, megnövelem a btrfs partíciót és már ott is a + hely, amit bárhol felhasználhatok. Több partíciós ext4-nél ilyen lehetőség nincs. Az LVM a kettő között van.

szerintem egy átlag felhasználónak is lehet hasznos, pl ha a számára fontos (nem nagy ütemben változó dolgairól) készül óránkénti , naponta, havi snapshot... így bármelyik korábbi állapotába vissza tud állni análkül hogy szétmásolná külön mappákba vagy fájlnévvel őket... pl egy LibreOffice dokumentum véletlen felülmentése üres oldallal, amikor már majdnem kész volt (egy munkatársam megtette, igaz Windowson és szerencséjére volt shadowcopy :-), ami ez esetben hasonló eredményt tudott csinálni mint egy zfs vagy btrfs)

Persze a mentést nem helyettesíti, max kiegészíti. Részemről elég sokáig használtam Ubuntu + BTFS-t SSD -n laptopn "többnyire" megelégedettséggel... /a balance kapcsán volt némi fura tapasztalatom amikor egyszer elfogyott a hely, de az is megoldható volt :-) /

Szerkesztve: 2020. 07. 11., szo – 10:01

Changes/BtrfsByDefault

https://fedoraproject.org/wiki/Changes/BtrfsByDefault

openSuse is megtette, örülök hogy a Fedora is alapértelmezetté teszi (F29 kiadása óta használom btrfs fájlrendszerrel). 

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Én egyelőre biztosan megtartom az ext4-et Fedora 33-on is. Régebben próbáltam btrfs-t, nem vált be. Már nem emlékszem, mi volt a bajom vele, de furán viselkedett.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tesztelem a ZFS-t és BTRFS-t is és egy okoz 100% galibát, ha nem tiltom le az (SSD/HDD) írási gyorsítótárat. Lehet balgaság, de úgy vettem észre, hogy nem elég ha nincs engedélyezve, hanem kimondottan tiltani kell. De az is lehet az én gépemmel van a gond. XFS esetében olvastam még hasonló problémát vagy is az ajánlást.

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Eszméletlen ez a folyamatos toszkolódás linux fronton a sok fájlrendazer körül.

Nekem nagyon megfelel bármilyen fs alá az LVM. Meg jobb is, mert elválnak a rétegek, és szabadon tehetek bele bármilyen fs-t. Pendrive-ra f2fs-t - ha Windows miatt kell, akkor részben exfat-et - teszek, amúgy általában ext4 nagyon jó nekem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó is volt az, amikor a 10GB HDD négy felé particionálta némelyik distro és 50% használtság esetén vártam a csodát:)

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek