Btrfs v módu raid1 jako kořenový FS (diskuse)

[Radek Podgorny]

pokud si spravne pamatuju, tak snapshot-aware defrag byl prijat uz docela davno... pokud to v tvem pripade (na nejakem relativne modernim jadru) duplikuje bloky, je to bug...

[Aleš Kapica]

Hned v úvodu zápisu je uvedeno, že byl z větší části sepsán v podstatě před rokem. Stačí letmé prohledání netu ke zjištění že v souvislosti s touto funkcionalitou nějaké bugy byly.

[Radek Podgorny]

neboj, cetl jsem to (snad) pozorne... ...jen jsem z informace "zhruba pred rokem" nedokazal dekodovat, o ktery kernel slo.

btw, tuto informaci mate i na te odkazovane wiki, tam by to mohla opravit chtelo. (vlastne tam je o snaphot-aware zminka, ale o par odstavcu dal tam je ta formulace o duplikaci dat.)

[Aleš Kapica]

Řešil jsem během té doby hromadu jiných věcí. Tenkrát, když jsem na to narazil jsem to vzal jako fakt. Netušil jsem že jde o bug. Chystám se tu stránku na wiki aktualizovat - proto se tenhle blogpost otírá o řadu věcí jen velmi stručně. Mám v plánu sepsat blogpost k migraci z 60GB disků na 120GB. Sám jsem zvědav jak to proběhne, protože když jsem s tím před rokem experimentoval tak jsem na nějaké háčky narazil. Ovšem to bylo součástí fáze, kterou jsem shrnul do Přeskočím martyrium slepých uliček..

Jen tak na okraj - kdyby snad někdo řešil Btrfs v prostředí Pacemakeru, tak mám napsaného vlastního agenta, pro mounting souborových systémů, který nemá - na rozdíl od oficiálního agenta Filesystem - problém s Btrfs volume.

[Dimka]

Neni nahodou ten zvlastni stav po roce pro BTRFS typicky? Casem se proste zpomaluje az je nepouzitelny. To je ma zkusenost a podobnou jsem i cetl tady u nejake zpravicky.

[Radek Podgorny]

videl bych to spis na ten ssd. mam podobne zkusenosti s ocz. naopak, ja treba btrfs pouzivam asi na desitce systemu (single i raid1) a kdyz to clovek obcas defragmentuje, vse je v pohode a rychle (az na nektere extremni use-cases, ale to se da taky resit).

[erukos]

já mám stejný problém na rotačních discích

[Aleš Kapica]

Typický rozhodně není. Projevuje se pouze u mého notebooku a ani ne často, pravidelně, či v nějaké závislosti. Proto usuzuji spíše na problém na straně komunikace s SSD.

[lejonet]

Uz se z toho neztraceji data? :-/

[Aleš Kapica]

Tak z Btrfs jsem dosud během pěti let žádná data neztratil a to jsem pod ním dělal doslova psí kusy. Což ovšem o Ext4 napsat nemohu. Tam jsem se pořádně spálil během té doby dvakrát. Naposled loni v létě, když v sw raid6 poli odešel ze čtyř disků jeden. V životě by mě nenapadlo, jak by tak banální věc mohla nabourat i souborový systém nad raidem do té míry, že se z toho už nevzpamatuje bez ztráty dat.

[Andrej]

Ona se z toho někdy ztrácela?

[Max]

Menší chybka v článku : "Autoscan" / "Autosnap".

Jinak pěkný, osobně používám btrfs na backup serveru s aktuaálním debianem. Narazil jsem jen na jednu chybku - nešly mazat snapshoty, což blo opraveno v novějším jádře (v rámci debianu), takže stačilo jen zaktulizovat systém a zase ok. Backupu už asi rok a zatím maximální spokojenost. Několikrát mi i došlo místo (mou chybou), stačilo odmazat pár snapshotů a místo opět přibylo a fungoval jsem dál.
Teď tu mám 16TB externí SATA pole s RAID50, takže je na čase rozjet btrfs na backupy v trochu větším měřítku.
Zdar Max

[Aleš Kapica]

Taky bych rád vyzkoušel Btrfs na velkém poli v módu raid6, ale momentálně na to moc nemám čas ani technické možnosti.

[Jooky (inactive)]

Na konci spominane "zamraznie" ma skoro s istotu na svedomi "discard" volba vo fstabe.

Uvolnovanie blokov na SSD je "draha" operacia, ktora chvilu trva. Btrfs "upravu" metadat riesi novou kopiou danej sekcie a zmazanim povodnych dat. To moze vyustit do hromady TRIM prikazov na disk a tie k chvilkovemu odopieraniu I/O operacii.
Aktualne este len planujem prechod na btrfs, no podobnu vec som riesil aj s ext4. Vyhodnejsie mi vyslo nepouzivat "discard" volbu vo fstabe, ale pravidelne pouzivat fstrim. Ja na ext4 pustam fstrim len raz za tyzden. Ci to tak pojde aj na btrfs uvidim uz coskoro :o)

btw. reci typu "ono sa to casom spomaluje" mi pripadaju, ze ludia nepouzivaju realocate. Kazdy storage system, ktory pracuje s block level snapshotmi, casom fragmentuje data. Tym sa nasledne spomaluje a to jedno ci ide o zariadenie doma, alebo enterprise storage system. Kazdy jeden po nejakom case vyzaduje realocate, s cim sa nasledne obnovy "rychlost ako na zaciatku"

[Aleš Kapica]

Díky za tip. Zkusím tu volbu vyhodit a uvidím jestli se situace zlepší nebo ne. Ono "zamrzání" se totiž objevuje i u nových, větších SSD disků s jiným typem řadiče.

[Jooky (inactive)]

Ja som si take to "zamrzanie" vsimol, len ked som po veeelkom upratovani pustil fstrim. Teraz som na skusku vyrobil 10GB subor a nasledne zmzal. "rm" prebehlo rychlo a nasledny fstrim trval takmer 30 sekund.

root@lukas:~# time fstrim -v /
/: 12347772928 bytes were trimmed

real	0m29.471s
user	0m0.000s
sys	0m0.312s
root@lukas:~# 

Podrobnosti ako pouzivam SSD na mojom notebooku mam na svojej Wiki. Daj potom vediet, ci to odlozene "trimovanie" pomohlo.

[Aleš Kapica]

Tak i když je asi možná předčasné dělat nějaké závěry, zdá se že odstranění volby "discard" problém vyřešilo, protože jsem ho od té doby nepozoroval a ani se mi ho nepodařilo nasimulovat pomocí tvého příkladu. Takže velký dík!

Ono to tak i předtím vypadalo že se vzájemně tlučou nějaké IO operace.