CentOS 6 a aktuální verze btrfs

6.3.2014 09:03 | Přečteno: 1143× | kompy | poslední úprava: 11.4.2014 10:21

Stručný zápisek o tom, jak rozchodit aktuální btrfs na CentOS 6.

Předně upozorňuji, že aplikací tohoto návodu si můžete rozhasit komplet systém, takže to je na vlastní riziko

CentOS obsahuje v poslední verzi 6.5 poměrně staré jádro (2.6.32 + hromady RHEL patchů). Btrfs je v této verzi také poměrně staré. Pro svůj domácí NAS jsem chtěl použít RAID5, aby to bylo alespoň trochu ochráněné proti problémům disků. Jenže dodávané btrfs obsahuje pouze RAID 0,1, možná i 10. To je na domácí použití celkem overkill.

Takže co je cílem?

Dostat aktuální btrfs s aktuálními btrfs-progs do CentOSu.

Jak na to?

Budeme potřebovat 2 věci:

1. Aktuální jádro s aktuálním btrfs
2. Aktuální btrfs-progs (v CentOS je ve verzi 0.20)

Aktuální jádro

Můžeme použít například elrepo a jeho část elrepo-kernel, kde jsou balíčky pro long-term support (kernel-lt) a mainline jádra (kernel-ml). Podle potřeby aktuální verze (3.10 vs 3.13) si vybereme (já jsem zatím vybral kernel-ml).

Jen malé upozornění: tato jádra jsou pouze nakonfigurována pro potřeby CentOS, neobsahují žádné patche, takže ne vše musí fungovat!

Dalším krokem po instalaci (yum install kernel-ml) je nastavení bootování tohoto jádra: /boot/grub/grub.conf a změnit položku default na pořadí nového jádra - čisluje se od 0).

Tím je nastaveno použití nového jádra

btrfs-progs

Instalace btrfs-progs je více problémová. CentOS 6.5 neobsahuje aktuální verzi, ani jsem nenašel žádný repozitář, který by ji obsahoval. A nejsou vyhlídky, že by se tak někdy stalo, pravděpodobně se objeví až v CentOS 7. Musíme to tedy trochu obejít

Předně, CentOS/RHEL je enterprise verze od RedHatu. RedHat jako pískoviště používá distribuci Fedora. Takže lze předpokládat, že by balíčky mohly být do jisté míry kompatibilní. Tak se koukneme po aktuální verzi btrfs-progs (tj. 3.12) a tu nalézáme ve Fedoře 20

Mno ... nebudu z toho dělat detektivku. Ve výsledku, btrfs-progs vyžaduje ke svému spuštění GLIBC minimálně ve verzi 2.14. CentOS jej má ve verzi 2.12. Takže použijeme GLIBC verze 2.14 z Fedory 16. Musíme nainstalovat všechny 4 balíčky: glibc, glibc-common, glibc-headers a glibc-devel. Pak již půjde nainstalovat i btrfs-progs verze 3.12 a máme hotovo a zbývá jen se modlit, aby fungovaly všechny programy, co používáme .

Seznam balíčků, které jsem stáhl a nainstalovat na svůj NAS:

• glibc-2.14.90-24.fc16.9.x86_64.rpm
• glibc-common-2.14.90-24.fc16.9.x86_64.rpm
• glibc-devel-2.14.90-24.fc16.9.x86_64.rpm
• glibc-headers-2.14.90-24.fc16.9.x86_64.rpm
• btrfs-progs-3.12-1.fc20.x86_64.rpm

Ještě se sluší dodat, že takto přeplácnuté knihovny nejsou součástí updatovacího procesu a zůstávají v systému. Takže se to nehodí pro server, kam mají přístup i jiné individua, než my .

Závěrem, doufám, že to někomu pomohlo v pokusničení s tímto FS. Lepší volba by asi byla použít nějakou jinou distribuci, která má aktuální celý systém, ne jen jeho části. Kdo ale chce pohodlí CentOS a aktuální btrfs, mlže to mít :)

EDIT:

Tak jsem to chvíli takto používal. Celkem to jede, ale některé programy spadnou hned po spuštění (SIGSEGV). Není to tedy tak růžový, jak jsem čekal. Takže jsem raději celý server přehodil dle rad komentátorů na opensuse 13.1. Sice si musím zvykat na zypper a systemd, ale snad to nebude moc velký problém :).

       

Komentáře

[Max]

Tak to s tím glibc je opravdu fuj. Co tak si btrfs-progs zkompilovat ze zdrojáků?
Zdar Max

[kapo]

Mno fuj to je, ale vzhledem k tomu, že je raženo heslo, že API pro userspace se nesmí nabourat a musí být zpětně kompatibilní, tak bych se toho zase tak moc nebál.

Ale rozhodně mi to přijde příjemnější, než si zaplevelit systém buildovacími balíčky a hromadou -dev. Nehledě na to, že btrfs-progs mají tu závislost na glibc >=2.14 asi z nějakého důvodu (i btrfs-progs kompilovaný proti glibc 2.17 vyžaduje minimálne 2.14 a ve Fedoře 20 je glibc verze 2.18). Takže odhaduji, že by kompilace stejně neprošla.

[Leinad]

Souhlasím s poslední větou:

Lepší volba by asi byla použít nějakou jinou distribuci, která má aktuální celý systém, ne jen jeho části.

A moc nechápu tu další větu za tím o pohodlí, protože jak píšeš výše, tak jsi ztratil bezpečnost Centosu, takže jsi tam mohl dát libovolnou distribuci s kratší podporou. Dost možná nejlepší by bylo openSUSE 13.1, které bude Evergreen, takže bude podporované 3 roky a v této verzi se zrovna zaměřili na funkčnost Btrfs (kernel 3.11 obsahuje spoustu Btrfs patchů z novějšího, aby to jelo, co nejlépe).

[Vantomas]

A nebo když pohodlí CentOS, tak používat to pískoviště, aspoň se naučí na serveru bez GUI nastavovat IP adresy pomocí NetworkManagaru

[pavlix]

Vždyť to stačí naflákat do /etc/sysconfig/network-scripts, bez ohledu na to, zda běží NM nebo ne.

[Vantomas]

To není moc moderní přístup k věci No to bude časem unsupported, systemd bez NM odmítne

[pavlix]

To není moc moderní přístup k věci

V kontextu CentOS 6 není moderní přístup k ničemu.

No to bude časem unsupported

O jakém časovém horizontu mluvíš?

systemd bez NM odmítne

Když už vymýšlíš spiklenecké teorie, tak si aspoň zjisti základní informace.

[kapo]

Ztracená bezpečnost CentOSu je pro mne irelevantní, není to server napíchlej přímo do internetu.

Ten server mám nainstalovaný přes rok a půl. Server není vystaven do Internetu (jen některé virtuály). To, že se zrovna nějaká distribuce zaměří na podporu btrfs, ještě neznamená, že na ni hned přejdu, budu všechno reinstalovat a budu řešit zase spoustu jiných problémů. Nepoužívám to jen jako NAS.

Každopádně zápisek byl o tom, jak to udělat, ne o tom, jakou vybrat distribuci. To můžete vesele řešit jinde ;).

[kapo]

Jinými slovy řečeno, zápisek je o tom: ano, lze to udělat takto, ale má to takové klady a zápory. A zda jít stejnou cestou, to už si každý musí zvážit sám.

[Michal Kubeček]

Takže si to zrekapitulujme. Vezmete jako základ distribuci, jejímž smyslem je poskytovat support po dobu 7 a více let (bez toho supportu ve smluvním smyslu), čehož je docíleno mimo jiné tím, že celou tu dobu zůstáváte na stejných základních verzích klíčových komponent (tedy aspoň formálně). A pak do téhle distribuce bez váhání vrazíte v podstatě mainlinové jádro a výrazně novější glibc (navíc přeloženou jiným toolchainem a pro jinou distribuci). Nemohu si pomoci, ale mám problém pochopit smysl takového počínání…

[Šangala]

Po přečtení zápisku mě napadlo „rozkaz ten zněl jasně“ a po přečtení tvého komentáře mě to usměrnilo na „zničit krtka“…

[kapo]

Ne, pochopil jste to špatně.

Máme server pro domácí použití.

Vezmeme distribuci, jejímž smyslem je poskytovat support po dobu 7 let a do téhle distribuce chceme vrazit aktuální btrfs. Takže do ní vrazíme aktuální jádro a btrfs-progs (ano tyhle 2 komponenty jsou výrazně novější) a k tomu picneme o jeden stupínek novější glibc (přečtěte si to prosím znovu: 2.12 -2.14).

Z mého pohledu jediné, co může výrazně ovlivnit stabilitu, je právě to nové jádro. Btrfs-progs jsou jen wrapperem na ioctl jádra a glibc zachovává ABI.

Ono aby to bylo jasnější. Není to stavěné na zelené louce. Na tom serveru jsem za jeho život rozjel spoustu věcí a v poslední době a s "moderními" disky jsem byl donucen začít hledat nejjednodušší a nejrychlejší řešení, jak zvýšit jejich spolehlivost. Myslíte, že je vhodné při každém problému měnit distribuci jen proto, že jiná to zvládá v jediné vlastnosti lépe? Uvidím, jak se to osvědčí. Když to bude blbnout, tak budu muset hledat jiné řešení. Tohle berte jako PoC.

[Michal Kubeček]

Ne, pochopil jste to špatně.

Jeden z nás dvou.

Takže do ní vrazíme aktuální jádro

…z mainline. Vaši důvěru ve spolehlivost jader z mainline bych chtěl mít. Ba ne, samozřejmě že nechtěl.

a k tomu picneme o jeden stupínek novější glibc (přečtěte si to prosím znovu: 2.12 -2.14)

A vy se na oplátku zkuste podívat, co v případě glibc takový stupínek obnáší. Nemluvě o tom, že nejde jen o verzi, ale i o to, že byla přeložena jiným toolchainem a pro jinou distribuci. A že jste tím třeba přišel o řadu oprav, které už v tom CentOSu byly.

Z mého pohledu jediné, co může výrazně ovlivnit stabilitu, je právě to nové jádro.

A to vám připadá málo?

Zkuste se zamyslet nad tím, že jste v distribuci, na jejímž udržování, backportech oprav a testování pracují desítky lidí, vyměnil dvě nejzákladnější komponenty, které používají všechny programy v systému. Jednu za v podstatě vývojovou verzi a druhou za verzi určenou pro úplně jinou distribuci. To je jako kdybyste v autě vyměnil "jenom" motor a podvozek.

Výslednou kombinaci dost možná nikdo jiný nepoužívá a nikdo ji nikdy netestoval. Jinak řečeno: to, co jste vyrobil, je na tom z hlediska spolehlivosti daleko hůř, než kdybyste rovnou vzal aktuální Fedoru.

glibc zachovává ABI

Upstreamová glibc a jedním směrem. V té distribuční "2.12" klidně mohl být backport něčeho, co naopak chybí v té 2.14, kterou jste vzal odjinud.

Myslíte, že je vhodné při každém problému měnit distribuci jen proto, že jiná to zvládá v jediné vlastnosti lépe?

Pokud se z nějakého důvodu rozhodnete použít "bleeding edge" filesystém, který ještě není příliš rozšířený, pak jste měl takovou volbu udělat ještě před tím, než jste ten systém začal instalovat. Trváte-li na BtrFS, pak podpora BtrFS měla být jedním z kritérií pro volbu distribuce. A Centos 6 byl v tom případě špatnou volbou, stejně jako by jí byla jakákoli jiná distribuce, která BtrFS nepodporuje a ze které kvůli němu musíte udělat DIY.

[pavlix]

To je jako kdybyste v autě vyměnil "jenom" motor a podvozek.

To zní jako by tyto komponenty v autě nikdy nikdo neměnil. Alespoň u motoru mi to přijde nanejvýš odvážný předpoklad.

Pokud se z nějakého důvodu rozhodnete použít "bleeding edge" filesystém, který ještě není příliš rozšířený, pak jste měl takovou volbu udělat ještě před tím, než jste ten systém začal instalovat. Trváte-li na BtrFS, pak podpora BtrFS měla být jedním z kritérií pro volbu distribuce. A Centos 6 byl v tom případě špatnou volbou, stejně jako by jí byla jakákoli jiná distribuce, která BtrFS nepodporuje a ze které kvůli němu musíte udělat DIY.

Na jednu stranu ano, něco takového se dá rozhodně doporučit. Na druhou stranu, jestliže se tak rozhodl s vědomím možných problémů, vyzkoušel si to a používá to ke spokojenosti, nevidím důvod se tím trápit.

[Michal Kubeček]

To zní jako by tyto komponenty v autě nikdy nikdo neměnil. Alespoň u motoru mi to přijde nanejvýš odvážný předpoklad.

Jistě, dělá. Takže to trochu upřesním: je to jako koupit si auto, které je symbolem bezpečí, solidnosti a spolehlivosti, řekněme Volvo (i když nevím, jestli to ještě pořád platí), a pak si říct, že to nějak nemá ten "odpich", tak si tam dám motor z něčeho, nad rozplývají Jeremy Clarkson s Richardem Hammondem v Top Gearu. Výsledkem bude paskvil, který nebude mít ani solidnost Volva ani živost toho sporťáku, takže by ve všech ohledech udělal lépe, kdyby si koupil rovnou sporťák.

Ale abych taky řekl něco konstruktivního… Trvá-li dnes někdo na BtrFS a zároveň chce spolehlivý systém, pak je asi jedinou volbou SLES 11 SP3. Přidáme-li podmínku, že to musí být zadarmo, pak se tomu asi nejvíc bude blížit OpenSuSE 13.1 (co se BtrFS týká), pro které navíc bude za pár měsíců k dispozici jádro založené na codebase SLE12 (na které se pak přejde v Evergreenu).

…s vědomím možných problémů…

Příspěvky autora blogpostu ve mně rozhodně nevzbuzují ten dojem.

[pavlix]

Jistě, dělá. Takže to trochu upřesním: je to jako koupit si auto, které je symbolem bezpečí, solidnosti a spolehlivosti, řekněme Volvo (i když nevím, jestli to ještě pořád platí), a pak si říct, že to nějak nemá ten "odpich", tak si tam dám motor z něčeho, nad rozplývají Jeremy Clarkson s Richardem Hammondem v Top Gearu. Výsledkem bude paskvil, který nebude mít ani solidnost Volva ani živost toho sporťáku, takže by ve všech ohledech udělal lépe, kdyby si koupil rovnou sporťák.

Pokud bude výsledkem auto, které neodporuje bezpečnostním předpisům pro provoz na silnici (čímž by byli ohroženi ostatní účastníci provozu), tak si myslím, že stačí dotyčnému svůj názor sdělit jednou. Buď ho přijme nebo nepřijme. Lidé mají různé zájmy, různé představy a různé důvody. A zrovna auto ve stylu anděl s ďáblem v těle má nepochybně své kouzlo.

[kapo]

Achjo. To musí být jako u doktora, kde než Vám vyříznou znaménko, tak musíte podepsat 2xA4 s výčtem možných následků včetně smrti? Kdo chce psa bít, hůl si najde. V úvodu je jasně řečeno, že to může rozbít komplet systém. Následků si vědom jsem, proto mám také důležitá data zálohovaná ještě na další místo.

Já jsem v době instalace systému zvažoval, co použít a hledal jsem hlavně jaký FS použít, aby uměl:

• přidávat disky za chodu
• umět konverzi po čase na RAID5 (až bude dost disků)
• umět minimálně checksumy nebo nějakou kontrolu integrity dat (což se mi už několikrát vyplatilo s dnešními >=3TB disky) - jste alespoň schopen odhalit, že k chybě došlo)

Teď mi prosím poraďte, které řešení tohleto umělo před rokem a půl. Které to umí dnes? A je samozřejmě dostatečně rychlé. A mějte při tom prosím na vědomí, že jde o domácí řešení, které běží na HW N54L/N40L s 4GB RAM.

Mělo SuSE už v té době ohlášen support btrfs? Pokud ano, pak jsem nedostatečně hledal.

P.S. ZFS, XFS, Ext234 nad DM ... nic to nesplňovalo a nesplňuje ani dnes.

[Vantomas]

A proč to nezvládá normální software raid? Už několikrát jsem převáděl RAID1 na RAID5, už několikrát jsem přidával disk za běhu a jednou týdně se mi spouští kontrola integrity pole, kdy se přepočítávají všechny parity a zjišťuje, zda nějaký disk není vadný.

[Šangala]

Integrita u mdadm a checksum-y je krapet rozdíl, nejde o vadný disk, ale o vadná data.

[Heron]

BTRFS jde krapet dál. Jednak ví, které bloky jsou zabrané soubory a které ne, tak po přidání disku potom operace balance pracuje pouze s bloky obsahující data. Je to mnohem rychlejší. Scrub totéž, projde a zkontroluje checksumy bloků, pokud narazí na nesouhlasný tak jej nahradí z jiného disku (pokud je) a tuto skutečnost včetně cesty k poškozenému souboru napíše do logu (je možné je případně obnovit ze zálohy). Software raid kontroluje všechny bloky a to ještě různě podle typu raidu. U zrcadla kontroluje, zda obě zrcadla vzájemně souhlasí (a neumí poznat, které z nich obsahuje správná data, pokud nejsou stejná), a u raid5 se kontroluje parita (a opět neumí poznat, co je správně).