Dotaz: ext4 či btrfs

[Dejmon]

Mám taktéž SSD disk. Téma na vytvoření oddílů pro SSD disk tu prakticky chybí, a v tématu "SSD disk a linux" je podle "lertimir" vhodné založit nové téma. Tak tu je a doufám, že pomůže hodně SSD-dákům

Odpovědi

[Jendа]

Kdybych si desktop instaloval teď, tak určitě použiju btrfs, lhostejno zda na HDD nebo SSD. Kvůli kompresi a FS-level snapshotům.

Překvapilo mě, že jsem tu nedávno četl, že nějaký disk má erase block 1MiB+512KiB. Ne vždy to může být snadné zjistit a já jsem si myslel, že se správně zarovnává na mocniny dvojky.

[béďa]

Slovo k tazateli: Předpokládám, že ti "lertimir" taky poradil, že máš stejný dotaz napsat hned dvakrát. Jeden z nich by se měl hned smazat.

Osobně jsem na SSD bez hlubšího uvažování použil ext4 a při nastavení doporučovaném pro SSD to jede dobře.

[Dejmon]

Nevím jak, ale povedlo se mi to sem dostat 2x, ale už to asi ajtík smazal. Co se týše SSD, tak mám dva, jeden 256 a druhý 128 GB, na obou mám LinuxMint. Menší mám v záloze, kdy se neco pokazilo na jiném noteboku či tak nějak, na druhý jedu, mám zde ještě vše jak na HDD, takže i swap i ./tpm a klasiku na ext4. Takže nevím, a doufám že mě disk vydrží dlouho. Když si tak pročítám fóra ohledně zápisů. co má co který SSD disk vydržet, tak stejně doházím k názoru, že ho svojí potřebou ani neupíšu a musí mě vydržet minimálně 3x více než udává sám výrobce a co se píše po různých fórech. To jen tak k SSD a tak dále a tak dále, aby to tu jen tak nestálo a dělo se tu něco )))))))) ---- PS- hned mě ale prosím neukamenujte

[lertimir]

Mam dojem, ze erase block je 512k bunek v podstate vsude v soucasnosti. Kdyz ale do bunky nacpou 3 bity tak dostanou 1536k bitu bloky.

[Šangala]

300 let jedu s ext4(ext3, Bubuntu 8.04/16GiB SSD) na SSD, po btrfs pomalu šilhám, ještě dva tři roky (což se bude asi i rovnat výměně desktopu) a už by mohl být dostatečně stabilní a odzkoušený, že do něj půjdu, ale pro velkou většinu lidí už tomu tak je fčul. Nicméně si myslím, že použít btrfs jen proto, že mám SSD mi přijde zbytečné a možná přinese víc problémů než užitku. Btrfs bych použil primárně pro jeho vlastnosti (pokud jich využiješ). Jestli se nepletu, zarovnával jsem na 2MiB (poslední, co mám v NTB by měl mít erase blok 512KiB)

[Pavel 'TIGER' Růžička]

Zatím pořád jedu na ext4, na btrfs podle mne nenadešel ještě správný čas.

[Max]

Já si to nemyslím. Třeba vím o člověku, co provozuje btrfs nad drbd, má nad tím několik VM, snapshotuje jak o život, shazuje a nahazuje drbd nody jako by se nechumelilo a btrfs jede jak drak.
Já na btrfs mám postavený backup v jobu, prostě rsync + snapshot. Párkrát mi i došlo místo na nulu a pokaždé jsem uvolnil a nebyl problém, jelo se dál. A vím o dalších lidech, co mají btrfs nasazeno a bez problémů.
Je ovšem pravdou, že jde vesměs o lidi s aktuálnějšími kernely. Já mám backup stroj na debianu, ale používám aktuálnější kernel z backports. Na ntb mám arch linux a ssd + btrfs. Na PC mám to samé. Člověk, co jede drbd+btrfs má debian, ale s vlastním, aktuálnějším jádrem.
Kdo používá Fedoru, RHEL7, Ubuntu, Gentoo, Arch linux, tak by neměl mít s btrfs problém. Kdo používá debian stable, tak doporučuji kernel z backports a také by neměl mít problém.
Dále jsem koukal na jednu zajímavou věc. Díval jsem se po nástrojích pro win, na obnovu FAT32 a hádejte co, už mívají v support listu kromě NTFS+FAT3+EXT i BTRFS. Viz třeba Active@ Partition Recovery.
Zdar Max

[kozzi]

Já si to nemyslím. Třeba vím o člověku, co provozuje btrfs nad drbd, má nad tím několik VM, snapshotuje jak o život, shazuje a nahazuje drbd nody jako by se nechumelilo a btrfs jede jak drak.

No tak zrovna neco podobneho jsme meli v praci, ale nakonec bylo btrfs nahrazeno ZFS a jedeto nekolika nasobne lepe.

Ale jinak sam osobne na svych desktopech pouzivam btrfs, pripadne jsem zkousel i F2FS, ten mel prekvapil perfektnim vykonem, ale take tim ze se mi rozesral a ja prisel o vsechny data ze slozek a souboru, ktere meli v nazvu diakritiku :D

[Max]

Jop, jinak tady v tomto threadu : Multidisk btrfs - oprava je jasně vidět, že btrfs na to už má a data lze vysekat i v prazvláštních situacích při selhání hw.
Zdar Max

[Jooky (inactive)]

Na Raid5/6 by som dal este pozor. Zvysne konfiguracie su safe. Ja aktualne ficim na 3.17.7-gentoo+aufs uplne bez problemov. Hromada suborov, snapshotov, etc. uplne bez problemov. Ext4 mam uz viacmenej len ako legacy a vramci vymeny HW / obnovy konfiguracie postupne prechadzam na btrfs.

btw: vramci nejakej zdravej paranoje doporucujem pravidelny short/long test cez SMART a btrfs scrub.

[Love_Dali]

Já jedu na ext4 na Vertex 4 už cca 2 roky a naprostá pohoda.

[Sten]

Dříve bych na SSD dal spíš NILFS nebo z něj udělal jen boost pro HDD pomocí bcache, ale btrfs je už dost stabilní (pokud nepoužíváte RAID) a má WAFL a optimalizace pro SSD. U ext4 záleží, jak dobrý má to SSD wear leveling, ale kvůli NTFS ho nejspíš všechny běžné SSD disky budou mít schopný (víc jsem to řešil u SD karet, tam je výhoda btrfs výraznější).

[Dejmon]

Díky, docela by mě zajímalo btrfs na SD kartách. Máš nějaké srovnávající údaje?

[Sten]

Mám SD kartu s btrfs v Jolla Phone, funguje dobře, přijde mi i rychlejší než s FAT v Androidu, ale to může být díky spoustě jiných věcí (víc RAM, nativní aplikace ap.). Předtím jsem zkoušel na SD kartách UDF, NTFS i ext4, to první celkem šlo, ty druhé dvě dokázaly tu SD kartu při častém kopírování upsat (asi kvůli žurnálu).

Co jsem četl, tak se nedoporučuje tam dávat cokoliv jiného než (ex)FAT, protože je to oficiální souborový systém a wear leveling je pro to optimalizovaný (resp. se výrobci neobtěžují s optimalizací i pro něco jiného). Ale protože btrfs je WAFL (včetně žurnálu, na rozdíl od ext4), tak vlastně dělá wear leveling samo o sobě.

[Dejmon]

Díky, dostatečná odpověď. Já jsem zkoušel také ext4, ale dělalo mi to neplechu, tak jsem tam strčil opět původní formát.

[Jooky (inactive)]

Ale protože btrfs je WAFL ...

Niesme nahodou kolegovia ? :o)

Ja btrfs preferujem hlavne pre:

- ma checksumy pre data / metadata, e.g. ochrana pred Silent data corruption / write lost. v redundantnej raid konfiguracii si vie najst spravne data a opravit poskodenu kopiu.
- btrfs je transakcny filesystem + kazdy zapis ide do volnej casti. Zapis sa bud dokonci, alebo su dostupne predchadzajuce data. Ext4 toto neriesi, journal je primarne pre metadata a nedokonceny zapis bez problemov necha rozhodeny obsah suboru
- snapshoty ... snapshoty a subvolume su uplne na nezaplatenie. Automaticke snapshoty mi robia prvu uroven backupov. V pripade zasahu do systemu, alebo prace s citlivymi datami spravim este jeden dalsi a hura do zmien na systeme.

[Andrej]

Btrfs.

[lertimir]

Oživovat 2,5 roku staré téma není úplně nejlepší nápad. Z hlediska FS na SSD myslím, že v součastnosti je to jednoznačně btrfs. Rewrite on place ty SSD čka zabíjí. Samozřejmě wear leveling se pokouší s tím něco udělat, aby to nebylo tak tragicky smrtelné, jako když se ext4 spustí na USB flash, ale přesto btrfs je zatím jediný FS, který si je vědom SSD a reaguje odlišně. Plus samozřejmě jeho vlastnosti, hlavně snapshoty.

[Dejmon]

Dá se za běhu předělat ext4 na btrfs? Samozřejmě bez ztrát!

[Andrej]

Konverze bez ztráty dat je možná, ale ne za běhu, pokud vím. Je potřeba oddíl s Ext4 odmountovat, provést konverzi a pak namountovat jako Btrfs.

[Kit]

Podle popisu by mohlo být teoreticky možné mít během konverze Ext3/4 přimountováno v režimu RO.

[Dejmon]

Zatím se do toho šťourat nebudu, co běží nebudu ...... . Až později, .......... bojím se

[Kit]

Podle dokumentace to vypadá reverzibilně do okamžiku, než se definitivně odstraní ext3/4.

Jako vždy: Zálohuj.

[frdrx]

Dá. Teď jsem to na svém notebooku v rámci příprav na další pracovní rok provedl.

[Michal2]

To je blud. Wear leveling funguje tak, ze pri zapisech stejneho bloku pouziva postupne cyklicky vsechny volne bloky (to je volne misto na SSD (pokud funguje TRIM) + rezerva). Takze je zcela, uplne a naprosto jedno, zda je FS COW nebo ne.

[Sten]

To záleží, jak dobrý je ten wear leveling. Ideální wear leveling tak funguje, ale pokud je ta implementace nějak zjednodušená (např. že alokovaný sektor má vždy totožných pár posledních bitů jako logický, protože tyhle bity se nezaznamenávají do alokačního logu, aby se ten log zmenšil), tak COW pomůže.

[Václav "Darm" Novák]

btrfs na celém SSD, home a usr jako subvolumes. Arch, žádný problém (A to jsem si prožil něco záseků a tvrdých restartů kvůli HW chybě) Doporučuji arch wiki a btrfs, mají to tam dobře rozepsané.

[Kit]

Přímo na celém /dev/sda (kam přijde Grub?) nebo na některém z jeho oddílů?

[Václav "Darm" Novák]

Na celém /dev/sda. Grub je klasicky v MBR a umí přistupovat do btrfs oddílů.

[Kit]

Aha, takže Btrfs nechá ten jeden sektor na začátku volný pro MBR, resp. Grub stage1. Další stage Grubu už jsou na Btrfs. Je to tak?

[Jendа]

Aha, takže Btrfs nechá ten jeden sektor na začátku volný pro MBR

To snad dělají všechny FS. Problém je v tom, že chceš i Grub 1.5, pokud necheš používat LILO-like blocks rozhraní.

[Kit]

I FAT?

[Sten]

I FAT, nazývají to reserved sectors

[Kit]

Ale ty tam nejsou default. A přiznejme si: Kdo z nás tam ty reserved sectors má?

[Sten]

Na FAT32 je default 32 sektorů

[Max]

Ne, další stage nemůže být na btrfs, protože další stage obsahuje driver na základní čtení z FS. První partition musí začínat nejlépe na 2048, aby se mezi MBR a začátek partition vešel stage1,5. Více info viz : Bootovací proces.
Zdar Max

[Kit]

Proto jsem se ptal. Nejlépe tedy Btrfs umístit do primárního oddílu, např. /dev/sda1.

[Václav "Darm" Novák]

Pokud tam necheš mít jiné primární oddíly s jinými FS je to naprosto zbytečné. Separování systémových oddílů se řeší přes subvolumes.

[Václav "Darm" Novák]

Jo ale bacha, je to špatný nápad pokud chceš mít swap, tam jsem trochu narazil. BTRFS neumí swapfile.

[Kit]

Swapfile musí umět. Snad swap partition, ne?

[pako]

Ono se to u ZFS neinspirovalo s implementací ZVOL (blokové rozhraní ke svazku)?

[Sten]

Ani swap file, protože vyžaduje pevná čísla bloků, která btrfs nezaručuje. Podpora je na TODO listu.

[Kit]

To zas někdo při implementaci swapu v souboru byl moc chytrej a obešel filesystém. Fuj.

[Sten]

Používá to čísla bloků ve filesystemu (ono to moc jinak řešit nejde, zapisovat to přes funkce pro soubory může skončit špatně, jelikož na to nemusí být pamět, když se swapuje). Kdyby obešel filesystem a psal bloky rovnou na disk, tak by se to nestalo.

[Jendа]

No ale FS může při zápisu říct „jé, já potřebuju další paměť, pojďme něco odswapovat“, ne? Blockdev ti tohle neudělá (snad).

[Václav "Darm" Novák]

Dá se to dočasně řešit swapem v loopbacku, ale není to zrovna nejrychlejší řešení.

[Max]

Proč subvolume jen pro "/home" a "/usr"? Proč né celý systém včetně "/" ?
Zdar Max

[Václav "Darm" Novák]

um, takhle / je subvolume a pod ním ještě subvolumes /home a /usr

[Tomáš Bžatek]

XFS.

[Kit]

XFS je fajn. Jen se občas stane, že se některý ze souborů zkrátí na 0. A to bývá hodně nepříjemné.

[Filip Jirsák]

Přičemž "občas" znamená jedině tehdy, pokud nedojde ke korektnímu odpojení souborového systému, typicky při výpadku napájení. A týká se to jen souborů, do kterých se v okamžiku výpadku zapisovalo (což ale kvůli kešování mohou být soubory, do kterých se z pohledu uživatele zapisovalo relativně dávno). Provozovat XFS na počítači bez UPS není rozumné.

[Tomáš Bžatek]

Wow, vsechny moje data byly poslednich 10 let v ohrozeni. Pomoooc! \o/

[Kit]

Zkus během zápisu do databáze vypnout kompl vypínačem.

[Jendа]

Rozumná databáze snad umí transakce/žurnál, ne?

[Kit]

Umí. Jenže pokud mezitím chybně uvažující FS zkrátí databázový soubor i se žurnálem na 0, tak s tím už DB engine nic nenadělá.

[Filip Jirsák]

Ještě mne napadá, že to zkracování na nulu tam bylo na začátku linuxového portu, ale později se to myslím změnilo a nezapsané soubory se na nulovou délku už nezkracují. To zkracování na nulu mělo ten důvod, že data v souboru by nejspíš nebyla v pořádku, takže je lepší je úplně zničit, než aplikaci předhodit nějaké smetí. Pak se názor změnil, že lepší zachovat alespoň část dat ze souboru než vůbec nic.

[Kit]

Zrovna databáze by se mohly dobře poprat i s tím smetím.

[Filip Jirsák]

Já jsem na databáze myslel naopak u toho zkracování na nulu Lepší zjistit hned, že jsou data poškozená a obnovit je ze zálohy, než do databáze dál zapisovat a později zjistit, že některá data jsou poškozená nebo chybí. Ale transakční databáze by se s tím smetím vyrovnat měla, resp. měla by potvrdit transakci až tehdy, když udělá sync a data jsou fyzicky zapsaná na disku.

[Kit]

Myslím si, že například PostgreSQL jen tak na kolena nedostaneš. Tedy pokud ji nezabiješ zkrácením na nulu. Správně nastavený SQLite také snese hodně. Opět jen do doby, než ho zkrátíš na nulu (nebo nenasdílíš na Sambě či NFS).

[Leinad]

Nedávno mě btrfs vypeklo s tím, že došlo místo. Příkaz df hlásil dostatek volného místa, ale btrfs fi show ukazoval zcela plný disk. Je docela nepříjemné myslet si, že vše je ok a při zapnutí systému jen vidět hlášku systemd, že došlo místo a mít systém, který nenaběhne do grafiky.

[Max]

To tě nevypeklo btrfs, ale ty sám :).
Zdar Max

[Leinad]

SSD mají obvykle méně místa a Btrfs žere více místa. Btrfs nespolupracuje s běžnými systémovými utilitami. Běžné smazání souboru v btrfs nemusí uvolnit žádné místo. To jsou podle mě věci, které objektivně komplikují použití btrfs na SSD, pokud uživatel není poweruser.

[Nicky726]

Záleží na fíčurkách, které se používají. Jinak bych tedy rád, kdyby df, du a spol. dokázaly zjistit, že pracují na btrfs a zjistit správným způsobem správné údaje. Zároveň si ale myslím, že by i uživatel měl mít nějakou představu o tom, co používá.

[Sten]

Problém je, že u btrfs neexistuje jeden údaj. Třeba obsazené místo může být buď místo skutečně obsazené místo (to zobrazuje df teď) nebo veškeré alokované místo, volné místo může být nealokované místo nebo nealokované + neobsazené alokované místo (to zobrazuje teď), součet volného a obsazeného místa se nemusí rovnat celému místu (jak budete počítat procenta obsazení?) a tak dále. K tomu data a metadata mohou používat (a ve výchozím stavu i používají) různé úrovně RAIDu a totéž časem budou moct i subvolumy.

[Nicky726]

Já vím, že je to s daty o využití btrfs složitější, ale přišlo by mi lepší toto přiznat, třeba i ve formě nejméně tolik, nejvíce tolik, či přímo hodit výstup z nástrojů pro btrfs, která tato na interpretaci složitá data dávají.

[lertimir]

btrfs je jediný FS, který má alespon částečně optimalizaci pro SSD. Mount volby ssd nebo ssd_spread.

[Jendа]

Mount -o ssd_spread is more strict about finding a large unused region of the disk for new allocations, which tends to fragment the free space more over time. Mount -o ssd_spread is often faster on the less expensive SSD devices. The default for autodetected SSD devices is mount -o ssd.

Je to na SSD, které do toho neznámým způsobem zasahují, vůbec k něčemu?

[Sten]

U btrfs nejde kvůli jeho alokační strategií správně odhadovat volné místo, btrfs se tak pro df snaží něco odhadnout, ale je to jen odhad. Navíc df ukazuje skutečně alokované místo, zatímco v btrfs může být veškeré volné místo prealokováno třeba pro metadata, a tak nejde alokovat pro data, což vyřeší jen rebalance:

btrfs fi balance /