Dotaz: BTRFS - jak opravit RAID 1 po výpadku disku

[vandrovnik]

Dobrý den,

v BTRFS nám odešel jeden ze dvou disků. Vadný disk šel na reklamaci, příslušný svazek byl prozatím připojen s parametry "compress=zlib,noatime,degraded". Nyní máme vyreklamovaný disk zpátky, ale BTRFS se chová tak, že:

- při pokusu o přimountování pro zápis s parametry "rw,compress=zlib,noatime,degraded" si stěžuje:

 mount -o rw,compress=zlib,noatime,degraded /dev/sdc1 /archiv
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so.
[ 3112.836056] BTRFS: missing devices(1) exceeds the limit(0), writeable mount is not allowed

- při pokusu o přimountování jen pro čtení s parametry "ro,compress=zlib,noatime,degraded" pak nejde přidat nový disk:

# btrfs device add /dev/sdb1 /archiv
ERROR: error adding device '/dev/sdb1': Read-only file system

Mohu zkušenější poprosit o radu, co s tím? Je tam Centos 7.3.

Díky, KR

---

---

Odpovědi

[kamen]

neporadim vam konkretne, ale protoze z vaseho dotazu si domyslim, ze s tim nemate zkusenost (s vymenou disku v btrfs raid1), silne doporucuji si sehnat jeste jeden disk a udelat si bitovou kopii toho funkcniho disku, pred tim nez budete cokoliv zkouset. samoztrejme zalezi na tom jak moc jsou vase data dulezita. bezny disk dnes stoji do 5kczk, coz skoro vzdy stoji za to.

pokud (ale z dotazu to nevypada) mate raid1 udelany jako blokove zarizeni MD (mdraid), pak staci pridat disk do pole a pockat az se sesynchronizuje.

[Max]

Vygooglil jsem toto :
Btrfs RAID1: How to replace a disk drive that is physically no more there?

Kde výsledkem je komentář s dvěma linkama :
raid1: cannot add disk to replace faulty because can only mount fs as read-only
kernel patch
Vypadá to na tvůj problém.
Snad se tu k tomu vyjádří někdo fundovanější, kdo si s tím už víc hrál.
Zdar Max

[vandrovnik]

Bohužel nic povzbudivějšího jsem také nenašel. Na kernel patch se opravdu necítím.

Někde byla zmínka, že připojit degradované btrfs v režimu pro zápis jde jen jednou (a opravdu šlo), tak asi jediná naděje, jak to opravit, by bylo najít a přepsat ten příznak, že už to rw přimountování jednou proběhlo.

[R]

Uzasna "feature". To akoze tento super-moderny filesystem, ktory okrem ineho ma nahradit aj ine vrstvy RAIDu, sa stane nepouzitelny pri vypadku jedneho disku z RAID1? To pisal nejaky teoretik a nikdy to v zivote nikto netestoval?

WTF?

Skvělej systém

[Petr]

Jde o znamou feature btrfs, kdy kdyz ti odejde 1 disk v raid 1 tak jsi v zadely a rw ho nenamontujes. Spravny postup je pry primountovat ho degraded mount -t btrfs -o degraded /dev/sda1 /archiv a pak btrfs replace start /dev/sdd1 /dev/sdc1 /archiv. Ty devices si uprav dle sveho skutecneho stavu.

[vandrovnik]

No, škoda, že tuhle "feature" člověk zjistí, až když se to po...

V read-only nefunguje btrfs replace, do write nejde v degraded namountovat.

Spíš si říkám, že to nově udělám tak, že RAID vytvořím pomocí mdadm a btrfs až nad ním, aby ty dva disky vůbec neviděl.

Ještě tak vymyslet, jak tam přesunout všechna data, protože co den, to snapshot...

[Max]

btrfs-send by snad měl na migraci fungovat.
Zdar Max

[citanus]

no vono je dobry se na pripadnou havarii pripravit predem... Nez neco nasadim v produkci tak otestuju DR.

[jekub]

Vy necetli, a presto rozmrazili? Wonderful! Bystry narod.

[Filip Jirsák]

No, škoda, že tuhle "feature" člověk zjistí, až když se to po...

To záleží na každém, kdy si přečte dokumentaci. Je dost lidí, kteří si ji přečtou před tím, než začnou používat něco, co má docela dost různých vlastností, přičemž je známo, že některé ještě nefungují správně (jako třeba RAID 5).

[karlik]

To mi připomíná výrok prodavače při reklamaci bot:

"Pane, vy jste snad v těch botech chodil?"

[R]

Ano, aj take sracky sa dnes predavaju. Nazyva sa to "vysoko modna obuv". Pritom to vyzera ako normalna obuv, ale hned sa rozpadne a reklamaciu neuznaju.

No a tento slavny RAID je na tom velmi podobne...

[petr]

Filipe, to je vymluva jako Hyundai. Kdyz jsem pred x lety porizoval Hyundai, melo to USB s podporou MP3. To, ze to podporovalo max 16GB usb, ze soubory museli mit lowercase mp3 extension, ze to ignorovalo soubory s jakoukoliv diakritikou nebo mezerami a ze mp3 nesmeli byt vbr ale jen cbr se mozna psalo nekde v dokumentaci, ale prodejce mi rikal o tom jak budu moci poslouchat muziku v aute. A vis co bylo nejvice k nasrani? Ze si to nepamatovalo last played song a furt to startovalo od prvniho souboru. Auto slo po pul roce z domu, misto slibovanych 7 litru zralo skoro 15. Tak nejak je to s btrfs, feature to ma spousty, ale ja to vidim tak se tech ruznych omezeni je proste spousta a dlouhou dobu.

[Filip Jirsák]

Jaká výmluva? Stížnost byla na to, že se o téhle vlastnosti člověk dozví, až když to nastane. Tedy Vandrovnik by požadoval, aby se o té vlastnosti dozvěděl dříve. Jedna možnost, kterou jsem uvedl, je ta, že si sám dobrovolně před použitím přečte dokumentaci. Napadá mne už jenom jeden další způsob, jak zajistit, aby se o vlastnostech dozvěděl uživatel předem – při instalaci mu zobrazit manuál, po manuálu bude následovat test, a teprve pokud ho dotyčný správně vyplní, bude instalace pokračovat. Což je u btrfs trochu problém, protože je to opensource, takže by se vzápětí objevil fork bez toho testu – a zase by si to někdo nainstaloval a pak si stěžoval, že se o vlastnostech nedozvěděl včas.

Nebo vy máte nějaký jiný nápad, než výše uvedené, jak zajistit, aby se uživatel o vlastnostech systému dozvěděl včas?

[vandrovnik]

No kdybych takovýhle bug implementoval ve svém softwaru, tak bych uživateli zobrazil jedno varování při vytváření RAID 1 a druhé varování v okamžiku, kdy by ten degradovaný svazek přimountoval rw, aby věděl, že to příště už rw nenamountuje (lepší samozřejmě se zeptat, zda opravdu chce rw, neb má jen jediný pokus).

Mohl jsem si pochopitelně lépe nastudovat dokumentaci, je možné, že se to v ní dokonce někde píše, to nevylučuju, ale při hledání informací o btrfs jsem na tohle prostě nenarazil a rozhodně mě ani náhodou nenapadlo, že by to mohlo být takhle hloupě udělané.

[R]

Presne tak. Neverim, ze sa takato sracka dostala do kernelu a nie je tam ziadne varovanie. Ked si predstavim, ze na tuto "feature" narazi Linus so svojimi datami, tak si viem zivo predstavit ten mail (a v nom pouzity slovnik), ktory by nasledoval...

[Filip Jirsák]

Jaký bug? O čem to píšete? Jediný problém je v tom, že pro odstranění vadného disku musíte souborový systém odmountovat a přimountovat v režimu degraded, a po odstranění vadného disku jej opět přimountovat v normálním režimu.

[alkoholik]

Kvuli vymene vadneho disku v RAID1 musim odmountovat fs? To je u me bug jako krava!

[Aleš Kapica]

O parametru remount jsi už někdy slyšel?

[alkoholik]

Jirsak jasne pise "musíte souborový systém odmountovat". Nekdo z vas dvou tu teda keca.

[Aleš Kapica]

Jirsák jasně napsal:

musíte souborový systém odmountovat a přimountovat v režimu degraded

Tak neargumentuj jak Miloš Zeman, ok? Parametr remount dělá totiž přesně tohle, akorát že v jednom příkazu.

[trekker.dk]

Parametr remount dělá totiž přesně tohle, akorát že v jednom příkazu.

Remount se u btrfs chová odlišně od ostatních filesystémů? Pokud ne, tak se mýlíte - remount souborový systém neodpojí, pouze změní nastavení toho připojeného mountpointu.

[Aleš Kapica]

Kromě toho je zcela evidentní, že ti uniká podstata věci. Tím že přemountuješ do režimu degraded jenom říkáš, že se holt dočasně extenty nebudou replikovat. Defakto jsi tím donucen problém řešit a ne že to necháš jet s neúplným raidem, než ti to exne všechno.

Pokud ti zůstane disků víc než jeden, tak to vůbec dělat nemusíš, protože si ten FS ty extenty přeháže rovnou a po tobě bude jenom chtít abys vyhodil ten vadný disk. Kapišto?

Jenže v době opojení ultratenkými notebooky mezi ušima funkční nervovou uzlinu abys pohledal.

[Filip Jirsák]

Kvuli vymene vadneho disku v RAID1 musim odmountovat fs? To je u me bug jako krava!

V tom případě nevíte, co je to bug. Bug je chyba, program neplní to, co je jeho účelem. Tady se ale bavíme jenom o nedostatku v použitelnosti – souborovému systému nějak musíte dát najevo, že řešíte problém s diskem, tedy že je v degradovaném režimu. Jediný nedostatek spočívá v tom, že to musíte udělat pomocí remountu, že to nemůžete nastavit jako příznak běžícímu souborovému systému.

[alkoholik]

To neni bug, to je feature!

[vandrovnik]

Problém je v tom, že jakmile btrfs s raid 1 jednou namountujete v degraded režimu pro read-write, tak už později nemáte možnost přidat nový disk. (Což jsem u žádného jiného systému pro raid neviděl.)

[Aleš Kapica]

Co to je za pitomost? Jak už jsem napsal o kousek výše. V degradovaném režimu vypnete replikaci extentů. Ale jinak by disk měl jít normálně přidat. Ovšem nevylučuji, že s tím verze btrfs tools, kterou jste zkoušel použít, má problém. Ovšem to lze jen těžko posoudit, na to co jste se vlastně s tím pokoušeli dělat křišťálovou kouli nemám.

[vandrovnik]

No, měl by jít přidat, taky jsem o tom byl přesvědčený. Ale nešel

Co jsem s tím dělal, je napsané hned v úvodním dotazu.

Umřel disk, po restartu jsem btrfs pro archiv provozoval v degraded režimu, read-write. Přišel nový disk, takže vypnutí, instalace disku, zapnutí - a už nebylo možné disk přidat, protože v degraded režimu naběhne jen read-only (a přidání disků neprojde).

Novější verze prý umí přidat jakýsi globální hot-spare disk, verze na Centos 7.3 to ale neumí.

btrfs version
btrfs-progs v4.4.1

[Aleš Kapica]

Tak. Ten disk byl zároveň systémový, nebo ne? Pokud ano, je nutné udělat ty opičárny v ramdisku, kdy nic na ten disky nezkouší zapisovat. Pokud ne, lze je udělat normálně když je systém v běhu.

Pokud jste provozoval Btrfs v degraded módu, pak to znamená jen to, že měl zakázáno replikovat extenty. A v degraded módu by měly jít disky normálně přidat, i když je FS ve stavu read-only. Ale jak už jsem psal, nevylučuji, že s tím má ta starší verze btrfs-progs problém. Ovšem něco to muselo napsat, nebo ne?

Jinak pokud jde o Btrfs, tak jednoznačně platí - čím novější jádro a btrfs-progs, tím lépe. Protože od jádra 4.4 se udělalo docela dost změn. Osobně mám velice dobrou zkušenost s jádrem 4.6, 4.9 a 4.12

[vandrovnik]

Disk systémový nebyl. V read-only disky přidat nešly - kdyby šly, bylo by to snadné.

[Filip Jirsák]

Umřel disk, po restartu jsem btrfs pro archiv provozoval v degraded režimu

Proč?

provozoval v degraded režimu, read-write vs. protože v degraded režimu naběhne jen read-only

Protiřečíte si. Možná si po sobě ještě jednou přečtěte svůj dotaz a výpisy v něm uvedené – abyste zjistil, co se doopravdy dělo. Problém byl v tom, že jste z btrfs odstranil disk (logicky, ne fyzicky) před tím, než jste přidal náhradní. Tím pádem se počet připojených disků (ať už bezvadných nebo vadných) snížil pod počet požadovaných disků a proto šel přimountovat jedině v read-only režimu. Btrfs se vyrovná s tím, že je nějaký disk vadný nebo fyzicky chybí. Ale špatně se vyrovnává s tím, když mu správce řekne „vše má být uložené alespoň na dvou discích, tady na to máš jediný disk“. Protože btrfs pozná, že to je nesplnitelný požadavek, a že tedy správce asi dělá nějakou hloupost.

Jinak kdybyste si vygoogloval „btrfs degraded mode“, najdete spoustu popisů, jak se má vadný disk v btrfs RAIDu vyměnit. Celý problém byl v tom, že vy jste se na to vrhnul, nevěděl jste, jak to máte udělat, a když vás btrfs začal varovat, že asi něco děláte blbě, ignoroval jste to a dál jste se to snažil dělat svým způsobem.

[vandrovnik]

Umřel disk, po restartu jsem btrfs pro archiv provozoval v degraded režimu

Proč?

Protože nám přišlo lepší po dobu reklamace mít archiv na jednom disku než ho nemít vůbec.

provozoval v degraded režimu, read-write vs. protože v degraded režimu naběhne jen read-only

Poprvé to v degraded v read-write funguje. Po restartu to v degraded už v read-write nelze namountovat a musí se jen read-only, ve kterém ale v téhle verzi nejde přidat nový disk. (To je ta "feature", o které jsem nevěděl, a kterou považuju spíš za bug než výhodu.)

[Aleš Kapica]

Nezlobte se na mě, ale poněkud mě zaráží situace, kdy nemáte po ruce ani jeden náhradní disk a musíte čekat, než vám přijde z reklamace ten starý, nebo náhradní.

Druhá věc co mě zaráží, že vám to normálně v degraded režimu ve stavu rw jelo a teď najednou ne. To byl ten stroj po celou dobu bez restartu? Jestli na to nejde udělat rw remount už teď asi zřejmě nevyzkoušíte.

[vandrovnik]

Je to jen jedno z míst, kde jsou zálohovaná data. Žádný restart mezitím opravdu nebyl, ten vadný disk byl pryč tak 10 dní.

[Filip Jirsák]

Poprvé to v degraded v read-write funguje. Po restartu to v degraded už v read-write nelze namountovat a musí se jen read-only, ve kterém ale v téhle verzi nejde přidat nový disk. (To je ta "feature", o které jsem nevěděl, a kterou považuju spíš za bug než výhodu.)

Akorát že žádná takováhle feature neexisuje, je to jen váš výmysl – a je to vidět např. v tom výpisu, který jste na začátku uvedl.

To, že šel souborový systém namountovat jen v read-only režimu, vůbec nesouvisí s tím, že to bylo po restartu nebo že jste to mountoval podruhé. Příčina je jiná – ta, že jste ten vadný disk z RAIDu logicky odstranil, tedy jste po btrfs chtěl, aby provozovalo RAID1 nad jedním diskem. Což samozřejmě nejde. Tady je to v tom vašem výpisu:

BTRFS: missing devices(1) exceeds the limit(0), writeable mount is not allowed

https://btrfs.wiki.kernel.org/index.php/Gotchas#raid1_volumes_only_mountable_once_RW_if_degraded

[vandrovnik]

Obávám se, že se mýlíte.

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg60979.html

[Filip Jirsák]

OK, máte pravdu, že tam zatím je tahle jednoduchá kontrola na počet připojení. Vždycky jsem degraded mód chápal jako režim pro opravu RAIDu, takže jsem ho nikdy nepotřeboval připojovat opakovaně.

[bigBRAMBOR]

tak ted teda nevím co je tam videt, kdyz ta feature existuje.

Akorát že žádná takováhle feature neexisuje, je to jen váš výmysl – a je to vidět např. v tom výpisu, který jste na začátku uvedl.

[Filip Jirsák]

Problém je v tom, že jakmile btrfs s raid 1 jednou namountujete v degraded režimu pro read-write, tak už později nemáte možnost přidat nový disk. (Což jsem u žádného jiného systému pro raid neviděl.)

Problém je v tom, že se s tím souborovým systémem snažíte dělat nesmysly. Degradovaný režim je jakýsi nouzový režim určený pro vyřešení specifických situací, např. odstranění vadného disku. Nechápu, proč se v takovém režimu pokoušíte do systému přidat disk. Disk se do systému přidává v normálním režimu.

A ještě navíc si vymýšlíte, přestože v tom výpisu nahoře je uvedené něco jiného. V tom výpise, který jste uvedl, máte pro oba dva případy jasně napsaný důvod, proč nejde udělat akce, kterou jste zamýšlel.

[Aleš Kapica]

A ještě navíc si vymýšlíte, přestože v tom výpisu nahoře je uvedené něco jiného. V tom výpise, který jste uvedl, máte pro oba dva případy jasně napsaný důvod, proč nejde udělat akce, kterou jste zamýšlel.

Já bych na něj zase tak ostrý nebyl. Je fakt, že když je člověk ve stresu dělá různé blbosti a pokud nemá zkušenosti, ani někoho kdo mu kouká pod ruce, tak o tom ani neví.

[Filip Jirsák]

Já bych na něj zase tak ostrý nebyl. Je fakt, že když je člověk ve stresu dělá různé blbosti a pokud nemá zkušenosti, ani někoho kdo mu kouká pod ruce, tak o tom ani neví.

Teď ale ve stresu není. A místo toho, aby si znovu přečetl svůj dotaz, kde má ty výpisy napsané, tak si vymýšlí věci, které jsou v rozporu s těmi výpisy.

To, že dělal hlouposti při samotné akci, bych pochopil (i když v okamžiku, kdy mi začne souborový systém na příkazy odpovídat chybami, radši bych si šel dohledat, jak se to má udělat správně, než abych dál souborový systém přesvědčoval, že se to udělá po mém). Kritizuju to, že teď, místo aby se snažil pochopit, jak to funguje, vymýšlí si věci, které jsou v rozporu s těmi výpisy.

[vandrovnik]

Nechápu, proč se v takovém režimu pokoušíte do systému přidat disk. Disk se do systému přidává v normálním režimu.

A to jde udělat? Když je vadný disk mrtvý, tzn. v tomhle raid 1 zbyl jen jeden disk? Přišlo mi, že abych disk mohl přidat, musím svazek namountovat. A abych ho mohl namountovat jen s jedním zbývajícím diskem, musím mountovat v degraded režimu.

[Filip Jirsák]

Musíte rozlišovat mezi vadným diskem případně chybějícím diskem, který je ale pořád součástí RIADu (takže btrfs ví, že je tam něco špatně a že je to selhání techniky, ne záměr administrátora), a případem, kdy disk odebere administrátor. RAID1 s tím, že administrátor poskytne jen jeden disk, zkrátka provozovat nelze. RAID1 lze provozovat tak, že administrátor poskytne dva disky, ale jeden z disků vykazuje chyby při čtení nebo je úplně nefunkční. V takovém případě přidáte do RAIDu třetí disk, řeknete, že nahrazuje ten nefunkční, btrfs na něj zmigruje data a teprve pak ten nefunkční disk z RAIDu odstraníte. To, že příčina toho, že se ten vadný disk systému nehlásí, je v tom, že jste ten disk dávno vytáhl a poslal na reklamaci, v tom nehraje roli – logicky musí být součástí RAIDu do té doby, než ho nahradíte jiným diskem. A nebo můžete snížit počet kopií, které po BTRFS vyžadujete (tj. zrušíte RAID1), a pak ten disk můžete (logicky) odstranit rovnou, protože není potřeba.

Pořád je to ten základní přístup, že když chce správce RAID1, poskytne dva disky a jeden z nich selže, je to věc, se kterou se btrfs umí vyrovnat – je to chyba techniky a s tou se v RAIDu počítá. Pokud správce řekne, že chce RAID1 a poskytne jenom jeden disk, je to logický rozpor, chyba správce – a to se btrfs nesnaží řešit, protože správce by měl vědět, co dělá.

[R]

Disk kludne umrie tak, ze uplne zmizne zo systemu. To programoval nejaky teoretik alebo je to len pokus o obhajenie neobhajitelneho?

[Filip Jirsák]

Disk kludne umrie tak, ze uplne zmizne zo systemu.

Ano, to je ten případ, kdy je disk úplně nefunkční.

To programoval nejaky teoretik alebo je to len pokus o obhajenie neobhajitelneho?

To jste jenom četl nepozorně můj komentář. I když disk úplně zmizí ze systému, pořád je to technická chyba, se kterou si btrfs poradí. A pořád je to něco jiného, než když administrátor ten disk svým zásahem vyřadí z RAIDu. Mimochodem, pro ten zmizelý disk má btrfs i speciální variantu příkazu – btrfs device delete missing /mountpoint. To klíčové slovo missing právě odkazuje na (první) disk, který v RAIDu úplně chybí.

[bigBRAMBOR]

správce řekne, že chce RAID1 a poskytne jenom jeden disk, je to logický rozpor, chyba správce to bude zase nejaka feature BTRFS, u HW RAIDu se toto bezne pouzíva. U nekterých výrobců je to dokonce jediná možnost jak přidat single disk.

[jekub]

Když jsem sestavoval poprvé sw raid1 na linuxu, také jsem nečetl celou dokumentaci. Ovšem první věc, než jsem to pusitl do provozu, byl test (resp. několik), jak obnovit rozbité pole.

[dustin]

Ale napadlo tě testovat to dvakrát, protože při prvním mountu degradovaného pole se podaří a při druhém už ne (viz to prapodivné počítadlo)?

[Filip Jirsák]

Nepomohlo by dvakrát to testovat, při druhém testu by to počítadlo běželo zase od nuly. Tenhle případ by navodil jedině tak, že by systém remountoval v degraded režimu, a pak, místo aby systém opravil, by jej odmountoval a znova přimountoval v degraded režimu.

[dustin]

Což je celkem běžná situace a očekával bych, že se bude chovat stejně. Možná by to udělalo i pouhé vypnutí/zapnutí stroje, ne?

Nicméně má reakce byla o tom, že se úvodním testováním takovéto "vychytávky" ani náhodou neobjeví.

[vandrovnik]

Ano, i reboot to počítadlo zvýší a rw už nelze namountovat.

[dustin]

Njn, co na to říct...

[Filip Jirsák]

Mně to jako běžná situace nepřipadá – znamená to, že nastane nějaký problém před rozhodnutím, jak degradované pole obnovit.

Zrovna v tomhle případě by se ta „vychytávka“ objevila, protože použít degradovaný režim btrfs RAIDu pro běžný provoz místo pro obnovu pole byl zjevně záměr, takže by se to tak mělo i testovat. A velice brzy by Vandrovnik přišel na to, že degradovaný režim je určený pro obnovu pole, a pokud chce souborový systém (byť dočasně) provozovat bez redundance, je potřeba souborový systém zkonvertovat na single nebo dup.

Možná je problém v odlišném postupu, kdy hardwarové RAIDy neumožňují snadno provádět konverzi mezi různými profily, takže umožňují provoz i v degradovaném režimu, kdy RAID sice nezaručuje ty parametry, které má mít, ale je v provozu alespoň nějak. btrfs naopak umožňuje profily průběžně měnit, takže když máte něco v RAID1 a chcete to dočasně provozovat bez jednoho disku, zkonvertujete to na single, a když později seženete další disk, zase to zkonvertujete zpět na RAID1.

[Jendа]

Umí to konverzi z RAID1 na single jenom přehozením metadat, nebo to musí znovu zapsat všechny bloky?

[Aleš Kapica]

Opět odkazuji na svůj zk..ý manuál (odkaz je výše), kapitola Balancing.

[Jendа]

No z toho jsem pochopil, že to je potřeba - ale doufal jsem, že tam třeba někdo dopsal inplace konverzi.

Takže místo „vypadl disk, pole se automaticky přehodí do degradovaného módu, a já jdu koupit nový; mezitím všechno normálně funguje“ to je „vypadl disk, nejde to namountovat rw, konverze na single nemá cenu, protože by běžela den nebo možná měsíc (1, 2 + osobní zkušenost na FS se zálohama se 150 snapshoty), takže služba prostě nepojede dokud nedojdu vyměnit disk“.

Dokud balancovaný souborový systém neobsahoval před balancováním žádná data, tak po vybalancování nebude obsahovat žádný datový extent. To není na závadu, pokud nemají být datové extenty ukládány v raid módu.

Pokud však mají být datové extenty kupř. v módu raid1, je třeba provést vybalancování po zapsání alespoň jednoho datového extentu. Jinak se datové extenty začnou zapisovat v režimu single, přes to, že při balancování byla pro datové extenty nastavena konverze na mód raid1!

LOL, to je lepší než jak kdysi implementovali kompresi, ale už neimplementovali dekompresi.

Já myslím, že teď už je naprosto jasné, že btrfs do produkce prostě nasadit nejde.

[Aleš Kapica]

Točíte se na obrtlíku napsaném před třemi lety.

[dustin]

A je to dnes jinak?

[Aleš Kapica]

Nevím, protože neřeším. Pokud dělám Btrfs v raid1 tak je dělám rovnou jako raid1. Konverzi single na raid1 jsem od té doby dělal jenom jednou a to už na tom poli data byly. Navíc se za ty tři roky dost hodně věcí změnilo. Stačí se podívat na changelog.

[Jendа]

Jenda: Jak to je implementované?

AK: Přečti si tento manuál.

Jenda: To je teda implementované pěkně blbě!

AK: Ten manuál je zastaralý a ve skutečnosti už je to jinak.

[Want]

Zkus to laskavě bez podsouvání. Nepsal jsem že je to jinak, ale že nevím jak je to nyní, protože mám na starosti jiné věci, než vodit někoho za ruku. Upozornil jsem na věc, která mě zaskočila tehdy. Takže kdo si to přečetl, věděl na co si když tak dát pozor.

[Jendа]

Zkus to laskavě bez podsouvání.

OK

Jenda: Jak to je implementované?

AK: Přečti si tento manuál.

Jenda: To je teda implementované pěkně blbě!

AK: Ten manuál je zastaralý a už to může být klidně jinak.

[Aleš Kapica]

Jenda: Umí to konverzi z RAID1 na single jenom přehozením metadat, nebo to musí znovu zapsat všechny bloky?

AK: Opět odkazuji na svůj zk..ý manuál (odkaz je výše), kapitola Balancing.

Jenda: …bla bla bla … nejde … bla bla bla … nemá cenu … bla bla bla … nasadit nejde.

AK: S takovou jdi do prdele milý Jeníku, protože ti to nikdo nenutí. A když máš zamálo se to naučit používat tak se dál cackej s čím chceš.

[Jendа]

Mám pocit, že ti někdo podstrčil úplně jiný text, než co jsem napsal.

[Aleš Kapica]

Vidíš, a není tomu tak.

[Filip Jirsák]

vypadl disk, pole se automaticky přehodí do degradovaného módu, a já jdu koupit nový; mezitím všechno normálně funguje

Jak jste přišel na to, že by to mělo být jinak?

[Jendа]

Z předchozího threadu jsem nabyl dojmu, že to po výpadku disku nejde namountovat více než jednou.

[Filip Jirsák]

No jo, tady se psalo nesmyslů… Po výpadku disku (pokud počet disků neodpovídá požadavané úrovni RAIDu) se jednou namountuje v degradovaném režimu, pole se uvede do stavu, v jakém má dále pracovat (což není stav, kdy je počet disků menší než požadovaná úroveň RAIDu) a pole se znovu přimountuje v normálním režimu. Jako není to zrovna user friendly a člověk při tom musí dávat pozor, co dělá, ale to by měl vždycky, když pracuje s polem v degradovaném režimu. Problém s tím mají především ti, kteří si jen tak pokusně přimountovávají pole v degradovaném režimu, jenom aby si vyzkoušeli, že to fakt jde.

[Jendа]

pole se uvede do stavu, v jakém má dále pracovat (což není stav, kdy je počet disků menší než požadovaná úroveň RAIDu)

Problém je v tom, že tohle uvedení nejspíš znamená přeházet na disku pár tera (a pak je tady ten faktor překvapení, mně se to taky stalo, protože - přiznám se - v dokumentaci jsem si toho nějak nevšiml a když jsem to zkoušel, tak mě nenapadlo zkoušet to přimountovat třikrát. Minimálně mně to přijde jako dost nečekaná vlastnost.).

[Filip Jirsák]

Proč by to znamenalo přehazovat nějaká data? Jenom se sníží požadovaný počet uložení jednoho bloku, to je jen zápis do metadat. Přehazování dat by to mohlo znamenat při složitějších konfiguracích, ale ne při 1+1 disk.

[dustin]

Pořád nechápu, co je normálního na tom, že se pole musí různě přemontovávat, dokonce se smí jen jednou (proč?). Prostě normální je vyměnit disk a spustit rebuild. Za běhu a plného provozu (hotswap) či mezitím to klidně několikrát restartnout (nehotswap, vypadne napájení s korektním shutdownem UPSkou, to vše se stává).

[Filip Jirsák]

Přemountování do degraded režimu je myslím nutné jedině v případě, kdy je potřeba z pole odstranit disk, který už se v systému vůbec nehlásí. Ano, je to divné chování. Pokud je disk vadný ale je vidět v systému, normálně se přidá nový disk, v btrfs se vymění za ten vadný a po rebuildu se ten vadný odebere.

To omezení na jedno přemountování se vztahuje jen na přimoutování s parametrem degraded v situaci, kdy máte méně disků, než vyžaduje aktuální úroveň RAID. A je to tak (snad zatím) z toho důvodu, že btrfs si v takovém okamžiku neumí zjistit přesný stav souborového systému a přizpůsobit se mu, takže místo toho dovolí správci jednou přimountovat souborový systém v degradovaném režimu a očekává, že během toho přimountování správce daný problém nějak vyřeší.

[dustin]

Normální je disk fyzicky vyměnit za jiný, ne přidat jiný (co když není volný slot?), počkat hodiny na zasynchronizování a pak odebrat ten starý poškozený, který mi mezitím může třeba dělat neplechu na napájecí lince, protože už má načatou elektroniku.

Nějaké předpokládání, že během jednoho mountu nedojde k výpadku napájení, to je... nic pro mě.

[Filip Jirsák]

Normální je, že ten náhradní disk už je v poli přidaný jako spare disk a použije se automaticky, nečeká se až někam někdo fyzicky s diskem přijde. Vyndavat zbytečně disk, na kterém je spousta čitelných dat, mi naopak jako moc normální nepřipadá – úplně zbytečně riskujete, že ta data necháte jen na zbývajících discích, odkud se budou muset při resynchronizaci navíc všechna přečíst (nejviditelnější je to na RAIDU1 se 2 disky – data necháte na jednom disku, ten zatížíte pro čtení dvojnásobně, protože musí zastat práci i za druhý disk, a jako bonus mu ještě naložíte přečtení celého disku). Pokud nemáte volný slot nebo odchází elektronika disku, je to větší výpadek, a v současné době to u btrfs bohužel znamená remount s -o degraded.

[dustin]

Spare je nesporně užitečný. Leč na méně kritických systémech to není standard - jako třeba ty naše dvoudiskové pracovní stanice, kde je raid kvůli úspoře času při výměně disku.

Vyndavat zbytečně disk, na kterém je spousta čitelných dat, mi naopak jako moc normální nepřipadá

Ten disk už je vyhozený z raidu, takže ničemu nepomůže, nijak se nepoužívá. Rozhodně nechci, aby z něj raid něco četl a pořád řešil jeho chyby. Nejlepší cesta, jak zaseknout SATA (možná i SAS) řadič i pro ostatní disky. Pokud bych jej potřeboval, jsou jeho data už stejně zastaralá. A nakonec nemusím jej hned sešrotovat, může zůstat na stole, dokud resync nedojede...

Jen mimo hru - jak se do btrfs raid1 přidá spare disk? https://btrfs.wiki.kernel.org/index.php/Project_ideas#Hot_spare_support tolik asi tak k tomu "hloupé zfs a md raid" od jiného diskutéra.

[Aleš Kapica]

Btrfs nepracuje s pojmem spare. Kdy už to probůh pochopíte. Btrfs v raid1 zajímá jenom to, aby každý extent putoval na dvě různá zařízení. Pokud máte dva disky, rozhazuje to mezi ně. Když jich máte víc, tak to rozhazuje rovnoměrně i přes ty ostatní. Když některý z nich chcípne, tak pro extenty které měly svůj duplikát na disku který chcípnul udělá tam kde je místo – ale opět na jiném disku než jsou extenty, které zůstaly.

A proč se takhle chová? Protože do toho luxusu, vyhradit jeden celý disk jako spare, se nikomu nechce. Takhle se využívají všechny disky rovnoměrně. A pokud je jich dost tak je to i bez starostí. Logika je prostá — souborový systém by nikdy neměl být zapráskaný tak, aby na discích nezbylo dost místa na to, aby se tam vešly datové exenty z disku který chcípnul.

Právě z toho důvodu je lepší mít Btrfs raid 1 sestavený z několika menších disků, než jenom ze dvou velkých. Ty jsou nejenom drahé, ale také pomalé a jakákoliv operace s nimi přináší akorát opruz. Jsou to jednoduché počty, ve kterých hrají roli otáčky, propustnost sběrnice, kapacita a cena. A pak jsou ještě další veličiny se kterými se dá počítat – hlučnost, spotřeba, teplo které je třeba odvést,…

Jinak pokud jde o výměnu disku. Já teda nevím, ale svoje stroje kvůli výměny disku restartovat nemusím. Stačí do boxu zasunout nový disk a původní disk nahradit.

V tomto bodě bych zmínil perličku. Kolega nedávno řešil disky a s překvapením zjistil, že při výrobě došlo k posunu číslování, takže uid kterým se disk hlásil v systému byl jiný než na štítku. A protože to byly disky z jedné série, tak to bylo posunuté u dobré poloviny z nich.

K čemu taková situace vede? No zjistíte který disk je vadný, vyndáte ho - a ajta krajta. On to byl zrovna ten klíčový co tam měl zůstat.

[dustin]

Díky za info. Vzhledem k tomu, že takhle složité věci obvykle obsahují spousty chyb a omezení (což je nakonec vidět), nic pro mě. Ale držím palce.

[RAID89564]

"Logika je prostá — souborový systém by nikdy neměl být zapráskaný tak, aby na discích nezbylo dost místa na to, aby se tam vešly datové exenty z disku který chcípnul."

Takze kdyz bude zapraskany, tak mi pole pojede bez redundance? To je nejaky novy slunickovy pristup k SPARE diskum? "Chcete SPARE disky? Ale my vime, ze je nepotrebujete!" S takovym debilnim pristupem bych se nedivil, kdybych u skoro zaplnenych filesystemu prisel i o data. BTRFS je evidentne zmetek urovne Win3.0.

[Filip Jirsák]

Vy tady pořád mícháte dohromady co nejlepší RAID a podprůměrný RAID. RAID se dvěma disky je takové šidítko, nemůžete od toho chtít žádné zázraky. Stejně tak ta výměna disku až když bude pořád hlásit chyby při čtení. Když ho vyměníte už v okamžiku, kdy začne odcházet podle SMART, neohrožujete pole tím, že v něm budete mít některá data uložená jenom jednou. btrfs vám hlavně umožňuje co nejlépe využít pořádný RAID. Pokud máte dvoudiskový RAID1, z pohledu RAIDu se na tom toho moc vymyslet nedá, takže tam btrfs nemá co nabídnout.

[dustin]

Nám většinu disků vyhodí pole při chybě ATA komunikace, což se ve smartu projeví až následně (ATA errors), pokud vůbec. Vždy jdou rovnou na výměnu a pokud byly v záruce (málokdy), nikdy nebyl problém s reklamací. Ke špatným/realokovaným sektorům ve smartu dochází spíše výjimečně. Takže smart to obvykle nijak dopředu neohlídá.

Používáme dvoudiskové md RAID1 pro stanice a mnohodiskové md RAID10 se spare pro interní servery. Externí na netu mají většinou HW raidy. Na interních serverech přejdeme na ZFS, především kvůli snapshotům pro konzistentní zálohy a zfs send/receive při vytváření externích záložních kopií, které se zatím dělají na zálohovacím serveru mirrorem md raid1 se zapnutou write-intent bitmapou. Jo, už jsme z nich za těch 15 let asi dvakrát datové pole zálohovacího serveru obnovovali.

[Filip Jirsák]

Jak jsem psal, na dvoudiskovém RAIDu podle mne nemá btrfs RAID co nabídnout, nevidím důvod nepoužívat tam md raid.

[dustin]

Tak to jsme asi došli ke stejnému závěru Díky za diskusi.

Jestliže se pole přehodí do degradovaného rw režimu, tak to je právě ten první pokus. A pakliže disk není hotswap, tak je potřeba vypnout a znovu zapnout počítač. A to další rw připojení je druhé a nazdar bazar.

[Filip Jirsák]

Tak pokud někdo dělá pokusy na produkčním systému… Já bych třeba pole jen tak pokusně do degradovaného režimu neremountoval. Když vím, že budu počítač kvůli vyjmutí vypínat, tak pole přimountuju v degradovaném režimu až po znovuzapnutí. Stejně bude po tom zapnutí konfigurace systému jiná (nebude tam ten disk), takže předchozí pokusný remount do degradovaného režimu je úplně k ničemu.

Ne tak jsem to nemyslel. V předchozích příspěvcích se psalo, že pole se automaticky přehodí do degradovaného režimu. Z toho jsem to odvozoval.

Tak co tedy udělá zapnutý btrfs raid1 v rw režimu, kterému odejde jeden disk do věčných lovišť? (Musím se zeptat, protože nemám, jak si to nasimulovat.) Pracuje dál, ale nadává? Přepojí se do ro? Přestane pracovat úplně? Co udělá?

[Jendа]

Pokud odejde za běhu, tak ti vynadá do dmesg (podobně jako MD RAID) a vše funguje normálně dál. Dokonce ho pak můžeš dvakrát :) odpojit a znovu připojit a potřetí už to nejde. (zajímalo by mě, jak se proboha stalo, že něco jde namountovat dvakrát a potřetí už ne -- jestli je to technická limitace (nenapadá mě jak se to povede), nebo tam je fakt counter, který ti ukáže prostředníček)

Takže disk odejde, systém nadává, ale jede. Já ho nervózně vypnu a v tu ránu už ho nenahodím, dokud nemám po ruce náhradní disk. To abych měl ještě náhradní systém, který by přebral funkci.

Možná by bylo lepší, kdyby se tahle fíčura dala nějak vypnout.

Nebo, jestliže btrfs ví, kolikrát byl namountován v degradovaném režimu, tak to bude někde na disku zapsané a možná by stačil nějaký hexaeditor a změnit nějakou jedničku za nulu.

[Filip Jirsák]

pole se automaticky přehodí do degradovaného režimu

Ale automatické přehození je něco úplně jiného, než ruční přemountování správcem. Automatické přehození do degradovaného režimu je provozní stav, se kterým se normálně počítá, od toho tam ten RAID je. Přimountování disku s parametrem degraded je způsob, jakým správce sdělí systému, že řeší ten problém, a ten parametr říká, že se má souborový systém připojit, i když je v degradovaném režimu (protože se připojuje právě za účelem opravy, ne za účelem běžného provozu).

Tak co tedy udělá zapnutý btrfs raid1 v rw režimu, kterému odejde jeden disk do věčných lovišť?

Pracuje dál a nadává.

Trochu divné je, že do tohohle stavu se lze dostat jedině s přimountovaným systémem, ale jakmile jej jednou odmountujete (třeba kvůli restartu), tak už se do něj nejde vrátit a btrfs vás před dalším mountem donutí nějak se tím zabývat. Na jednu stranu je to pochopitelné, protože RAID s menším počtem disků, než je požadavek, by se měl řešit co nejdříve. Na druhou stranu to vede k situaci, kdy je na nějaké vyřešení jenom jeden pokus, a bohužel jsou situace, které správce ovlivnit nemůže – třeba výpadek napájení. Zase je ale dobré dodat, že to počítadlo mountů v degradovaném režimu je podle odkazovaných e-mailů jenom dočasné řešení a plánuje se úprava, která bude kontrolovat skutečný stav filesystému. Navíc tahle situace je specifická pro RAID1 se dvěma disky, pokud těch disků bude víc a nebudou zaplněné až po okraj, nemělo by k téhle situaci vůbec dojít.

OK. Díky za vysvětlení.

[jekub]

Jelikož jsem s tím neměl žádné zkušenosti, tak ještě vícekrát. Od několika restartů po fyzicky odpojeném disku za běhu, restarty v průběhu syncu po připojení disku, ... Přišlo mi to jako samozřejmost.

[2017]

musim vas podporit. je odpovednost kazdeho kdo to nasadi si o tom zjistit jak to funguje. druha vec by byla, pokud by to byla nedokumentovana "featuresa"

stejne jako se zalohovanim. kdo zalohuje a nikdy si nenasimuloval zavadu a obnoveni dat, tak musi mit nekde v kredenci lahvicku s virem stesti.

[Want]

Ale jde. Dá se to ošidit, když tomu dáš nějaký soubor přes loop. Klidně vytvořený v tmpfs. On zkrátka potřebuje někam cpát ty věci, než mu dáte ten druhý disk. Pak se ten vadný disk vykopne a místo něj se dá nový. A pro změnu se vyndá ten druhý. A proč sem pletete md raid, který s Btrfs v raid 1 nemá nic společného?

[Max]

Uveď prosím příklad, nevím, jak to myslíš.
Mdadm zmiňuje proto, protože přemýšlí, že ho použije místo raid fce v btrfs, nevím, co je na tom k nepochopení. Pokud narážíš na případné nevýhody, nebo zbytečnost, tak z tohoto threadu tato myšlenka vzešla.
Jelikož jsi ani ty neposkytl řešení ("najdi si návod, co jsem psal", to je opravdu originální pomoc :) ), tak se mu není co divit.
Zdar Max

[Aleš Kapica]

Zdar Maxi. Nepsal jsem mu aby si našel návod co jsem psal, ale že pokud bude hledat, tak na něj možná při troše snahy narazí.

Jinak pokud jde o ten konkrétní problém. To mám zatím jenom ve svých poznámkách - ještě jsem to nepřežvýkal pro ty blbce Rozepsal jsem to, ale nějak se navalila jiná práce a už jsem to nestačil dotáhnout.

V kostce ale mohu odkázat na zdejší blogpost co jsem psal - Výměna SSD disků systémového disku s Btrfs v módu raid1. Je to v zásadě to samé co potřebuje vyřešit tazatel. Celý vtip je v tom, že musí nejdřív přidat nějaké zařízení, aby mělo Btrfs v raid1 splněnu základní podmínku: Mám možnost ukládat na dvě bloková zařízení. Pak přestane stávkovat a dá se normálně připojit readwrite. No a pokud to není zrovna loop do tmpfs, ale na něco co má dostatečně velkou kapacitu, tak je po problému. V podstatě jde o zcela normální stadardní postup. Nic extra. Takže tahle sekvence příkazů:

stroj :~# btrfs fi show /
…
        *** Some devices missing
stroj :~# btrfs device stats /
stroj :~# btrfs device add /dev/loop0 /
stroj :~# btrfs balance start /…
…
stroj :~# btrfs device delete missing /…
stroj :~# btrfs device stats /…

Aha show ukazuje že je nějaký disk v háji. No tak koukneme na stat, ať víme který, že. Pokud máme raid1, ale zbyl nám pouze jeden disk, musíme situaci nějak vyřešit, že? Kdybychom měli disků víc, tak tenhle krok můžeme klidně přeskočit. Tož přidáme nový disk. Bodneme do USB něco na čem se dá vytvořit alespoň prozatimně image, tu připojíme na loop0, přidáme jako nový disk a spustíme balance. Pak se zbavíme toho co je missing.

No a pokud chce používat ten disk zase jenom na jednom disku, tak holt musí trochu pohledat, našel by možná ten můj zk..ý manuál, tam by se dočetl něco o tom jak to vlastně funguje a třeba by mu došlo, že k tomu musí udělat balancing s konverzí extentů. Ovšem proč by to dělal, když chce jenom vyměnit disk, že?

Fakt nechápu co ty lidi vede k tomu, používat Btrfs v single mode a ještě jenom nad jedním blokovým zařízením, když jeho elegance vyniká až u raid1. Já už doma od md raidu dávno upustil. Nemám prachy na to, abych pokaždé kupoval 4 stejné, nebo pokud možno větší disky. Takhle mám ve stroji 6 disků, když jeden chcípne, tak si to Btrfs samo přeháže, místo na to má. A já pak jenom vyměním ten disk za nový.

[Aleš Kapica]

Důležitá poznámka - není jedno, jak bylo to Btrfs v raid1 vytvořeno! Nevím jak je to teď, ale u starších verzí bylo nutné, pokud se ze single mode udělal raid1 udělat rebalancing, aby byly zreplikované všechny extenty - píšu o tom v tom manuálu.

Zkrátka je třeba prozkoumat co vrací Btrfs pro device.

[xxl]

Dobrý zk..ý manuál . Díky. A taky díky tazateli, že se vůbec zeptal. Přimělo mě to konečně k vyzkoušení btrfs. A ty možnosti mě fakt zaujaly.

A i ten btrfs raid1 jsem dokázal sestavit, cvičně rozbít a zase opravit. Zase tolik práce to nedalo. Aby člověk opravil rozbitý mdraid, taky si musí něco nastudovat.

[Aleš Kapica]

Potěšení na mé straně. A to tam ještě fakt dost zajímavých věcí které mám v poznámkách chybí.

[Aleš Kapica]

Jinak ještě k tomu raidu u Btrfs. Problémový byl dlouhou dobu raid5/6, ale pokud vím už by to mělo být opravené. Ale ruku na srdce, když člověk pochopí, jak vlastně u Btrfs funguje raid 1 tak mu přijde nasazení raid5/6 až zbytečné. Proto to zřejmě u vývojářů nemělo až takovou prioritu. Rozdíl je totiž v tom, že datové extenty nejsou na dvou blokových zařízeních (jako u raid1) ale na třech. Ovšem jaká je pravděpodobnost, že chcípnou dva disky současně? Podle mě zhruba stejná, jako kdyby měly umřít tři a v takovém případě už je to úplně jedno.

Když mám tedy 4 disky, je lepší nad nima mít Btrfs v raid 1, než md raid 6 – jak jsem to dřív míval – a nad ním Btrfs v single modu. A úplně nejlepší je to mít tak (jak to mám teď já), aby v případě výpadku největšího z disků byly schopné všechny ostatní disky se o jeho kapacitu podělit.

[Max]

Pokud vím, RAID5/6 je stále u btrfs nepoužitelný, stále v režimu unstable a nedoporučuje se jeho používání s produkčními daty.
Dívám se na status u kernelu 4.12 a je to stále tak : BTRFS : Status(write hole still exists, parity not checksummed)
Další né moc pěkná věc je pak "gets stuck on devices with bad sectors".
Ještě čeká vývojáře hodně práce. Každopádně já osobně btrfs používám bez problémů, ale většinou na desktopu/ntb s jedním diskem, nikdy jsem u něj nezkoušel fce raidu.
Zdar Max

[Aleš Kapica]

Pokud vím, RAID5/6 je stále u btrfs nepoužitelný, stále v režimu unstable a nedoporučuje se jeho používání s produkčními daty.

Je to možné. Já ho taky nikomu nedoporučuji, protože Btrfs v raid1 bohatě stačí. Chápu že to tady někteří stále nedokáží pobrat jak to vlastně funguje. Také jsem měl z toho dlouho obavy. Používal jsem md raid 6, protože jsem měl 4 disky a byl jsem i v situaci, že dva z nich byly pryč. Byly vadné kontakty na jedné větvi u zdroje – od té doby se vyhýbám modulárním zdrojům jak čert kříži.

Btrfs v raid 1 ti poskytne totéž, pokud ti zbylé disky poskytnou dostatečnou kapacitu za ty co vypadnou. Navíc máš s dispozici další možnosti, jak v případě nutnosti uvolnit další místo (defragmentace, reflinky, rekomprese,…). Proto mám kupř. zcela záměrně vypnutou u Btrfs kompresi. Jednak to snižuje zátěž za provozu, a pak – když je zle, je kam sáhnout abych uvolnil místo.

U klasického md raidu vypadlý a opět přidaný disk znamenal 8 hodin resynchronizace. U Btrfs nic takového není.

[R]

Vypadnuty a znovupridany disk riesi write-intent bitmap.

[Max]

Tak tak, ale má to samozřejmě své režie :-/.
Zdar Max

[vandrovnik]

Jestli jste výpadkem napájení přišel o dva disky, tak raid 6 bude fungovat dál, ale btrfs raid 1 podle mého soudu ne - má data na dvou místech a pokud obě ta místa byla na těch odpojených discích...

[Aleš Kapica]

To je sice pravda, ale to ještě nic neznamená. Jakmile má ty disky zase k dispozici, normálně najede. U toho md raidu to tak jednoduše nešlo. Jinak ten systém by pravděpodobně nenajel a pokud by najel, tak by řval, že něco není v pořádku, protože by mu chyběly extenty co jsou na chybějících discích.

Btrfs raid1 neřeší všechny situace, ale řeší situaci kdy disky umírají postupně. Kupř. na notebooku ho používám proto, že na něm mám SSD. Zažil jsem několikrát chcíplé SSD. Vždycky to bylo náhle, bez příznaků a totálně. A opravdu nemám na to ztrácet čas reinstalací a obnovou záloh. Nehledě na to, že ten SSD disk může umřít v situaci, kdy se k nim ani nemohu dostat.

[Michal]

Zakladni myslenka RAID1 je takova, ze po vypadku disku vse funguje bezvypadkove, bez zasahu admina a hlavne RW jako by se nechumelilo. Produkce musi bezet, proto tam mam snad sakra RAID ne? Btrfs RAID1 to zjevne nesplnuje tudiz to neni RAID1 ale nejaka ... neco jineho.

[Petr]

To ale lidem co maji bŕŕŕfs nekde doma nevysvetlis. Stejne jim nevysvetlis to, ze raid1 ve kterem musi byt 3 disky jenom kvuli nedodelkum tohodle fs znamena +33% narust na storage costs a ono je to asi jedno u stroje ve kterem jsou 3 nebo klidne 20 disku, ale jestli mate tech serveru x stovek nebo x tisicu tak to jiz jedno neni. To same i io costs.

[Aleš Kapica]

RAID není primárně určen k tomu aby služba jela bezvýpadkově, bez zásahu admina. Ale k vytvoření úložiště s větší kapacitou, než umožňuje jedno blokové zařízení. A v případě raid polí vyšších než 0 odstínit souborový systém od chyb na blokovém zařízení. Což je přesně to co Btrfs dělá, pokud je v raid1 a má k dispozici více než jeden disk. Pokud tedy chceš aby ti Btrfs fungovalo bezvýpadkově, tak to nesmíš šmudlat jen se dvěma disky. Dej si tam alespoň tři a budeš mít k dispozici nejenom vyšší kapacitu, ale i to po čem toužíš - FS, který je schopen fungovat bezvýpadkově.

[petr]

Takze kdyz budu mit 1000 serveru, budu muset mit o 1000 disku navic kvuli brtfs logice ze v raid1 je zapotrebi minimalne 3 disky abych mohl fungovat nez se nekdo stavi do datacentra vymenit vadny disk. Takze treba o 200k$ navic investice. To by me sefove pochvalili. Kdyz odejde jeden disk v klasickem raid1, jede se dal a az se vymeni (treba u nas 1 tydne), tak se data syncnou. Kdyz selze i druhy, je aktivni jeste minimalne 1 stroj v ha poskytujici danou sluzbu a dany node se proste obnovi ze zalohy. Nekdy mi prijde ze btrfs muze do produkce obhajovat clovek co ma 2 servery s 5 disky a negarantovanou dostupnosti. S btrfs v produkci to musi byt Sranda.

[Filip Jirsák]

Vymýšlíte absurdnosti, a nějak jste se do toho zamotal. NA RAID1 nepotřebujete tři disky, stačí dva. Ale pokud máte v datacentru 1000 serverů a v každém dva disky, nejvíc ušetříte, když použijete diskové pole, které ty servery budou sdílet.

[alkoholik]

Ten ja fakt dobry.
;)

[Aleš Kapica]

Takze kdyz budu mit 1000 serveru, budu muset mit o 1000 disku navic kvuli brtfs logice ze v raid1 je zapotrebi minimalne 3 disky abych mohl fungovat nez se nekdo stavi do datacentra vymenit vadny disk.

Když budu mít 1000 serverů, tak použiju v prvé řadě distribuovaný souborový systém. A pak by bylo úplně jedno kolik v nich bude disků, protože bych je udělal disklessové. A pokud jde o vaše počty. Sorry, ale 6x 2TB je rozhodně lepší volba než 2x 6TB, Vyjde to lépe cenově, bylo by to lepší z hlediska výkonu a taky by to přineslo mnohem větší úspory při výměně disků co by odešly.

[MP]

No jak se to vezme

1] 2x6T vs 6x2T...cena je nyni bez dph 5k za WD RED 6T, 2k za 2T variantu, cili 10k vs 12k

2] performance...bude lepsi u 6x2T

3] hw...2x6T se vejde do 1U, 6x2T do 1U nenacpete, plus prislusny radic/pocet portu sata, ramecky atd

4] spotreba...maximalka je 3.5W u 6T, 4.4W u 2T, cili 7W vs 26.4W

5] nahradni disk...lepsi u 2T

[Aleš Kapica]

Ano jak se to vezme. Je výrazný rozdíl SATA versus SAS. 2.5-inch versus 3.5-inch. A enterprise versus obyčejný desktopový disk.

Pokud chceš mít servery 1U, tak tam nebudeš cpát 6x3.5-inch, ale dáš tam jen 3x3.5-inch a nebo použiješ šasi, které má 8x2.5-inch. Ovšem enterprise SAS disk o kapacitě 2TB nestojí 2K. Musíš si rozmyslet co chceš, jestli výkonné úložiště se spolehlivými disky, nebo low cost s disky co na to vůbec nejsou stavěné.

[Skokan, Pavel]

nezapomínejte na vlastní význam "RAID" - tedy Redundant Array of Inexpensive Disks

každý má své potřeby/možnosti nastavené jinak (jen pro příklad - když budu mít mini ITX desku na ní 2x SATA, na tom si udělám sw RAID1, tak to nikdy server s 8x SAS prostě nebude ... )

a pokud něco nazvete RAID1 (mirror je jasný a zavedený - co na jednom disku to na druhém disku), tak by se to tak mělo chovat, jinak to není RAID1, pak je to totiž zavádějící a vznikají z toho nečekané komplikace viz toto vlákno o chování btrfs s "RAID1" (dtto provoz v degradovaném režimu a výměna porouchaného disku ... )

[Aleš Kapica]

Ty komplikace vzniknou pouze tehdy, když nepostupujete tak jak máte. Správný postup je takový, že když vám ve stroji chcípne disk, strčíte místo něj nový a nahradíte ten co chcípl. A ne, že budete dál používat degradované pole, jako by se nechumelilo.

To že to umožňuje md raid ještě neznamená, že je to správně. U Btrfs je to zkrátka tak, že vás to situaci donutí řešit ať chcete, nebo nechcete.

[Max]

V tom je přeci svoboda, ne? Proč by mi měl někdo diktovat, co a jak mám dělat? Když chce někdo provozovat pole v degradovaném režimu, je to jeho věc (ať už jsou důvody jakékoli), ale řešení jako takové by to nemělo nijak omezovat, maximálně by na to mělo upozorňovat.
Zdar Max

[trekker.dk]

A i za takových okolností by se RAID1 měl chovat tak, jak má ve zvyku něco, co se nazývá RAID1 - fungovat, dokud někdo do toho pole disk zase nevrátí. A nevymýšlet nesmysly.

[Aleš Kapica]

Těžko se může chovat stejně něco, co funguje úplně jinak. Smiřte se laskavě s tím, že to není raid celého blokového zařízení, ale datových extentů.

[trekker.dk]

Takže to vlastně není Redundant Array of Inexpensive Disks, tedy raid, a nemělo by se to tak nazývat. Když už použili tenhle název, tak se měli držet sémantiky. Nebo to nazvat RAIDE.

[k3dAR]

prihodneji to meli (v BTRFS) nazvat spis PRDEL1...

[Aleš Kapica]

To máš pravdu. Na druhou stranu víš jak to chodí, když někdo něco zapinká, protože mu technologie dovolí, a pak všude troubí, že o data přišel díky špatné technologii. O své blbosti a šlendriánu taktně pomlčí.

To že je to s tím počítadlem jak to je, má zřejmě nějaký svůj důvod. A jelikož jde o věc, která zřejmě nikoho zase až tak moc nikoho nepálí, zůstává bez řešení, které by uspokojilo uživatele se sklony nechávat věci v riskantním stavu.

[dustin]

Přesně takový pocit riskantního stavu bych měl, kdybych na něco klíčovějšího nasadil BTRFS s tímto raidem a mohl jenom doufat, že se při výměně disku vše podaří správně, že před přidáním nového disku nevypnou proud (nebo jiný korektní reboot z jakéhokoliv důvodu), atd.

Ale za tuhle diskusi jsem moc rád. Už vím, co vůbec nemusím ještě hodně dlouho řešit.

[Filip Jirsák]

Nedělal bych unáhlené obecné závěry z okrajového případu (RAID1 nad dvěma disky, z nichž jeden kompletně odešel), na který není btrfs zaměřen a který lze řešit jinými nástroji (takže logicky nebude v centru zájmu vývojářů btrfs).

[dustin]

Raid1 ze dvou disků je pro mě konkrétně zcela klíčový případ (konzistentní snapshot na btrfs by potenciálně zlepšil zálohování pracovních stanic s dvoudiskovými raid1). A očividně zdaleka nejsem sám. A jakmile disk vrátí chybu a pole ho vyhodí, tak pro mě "kompletně odešel" a v poli ho nechci, žádný jiný stav neřeším.

Takže tohle pro mě rozhodně není unáhlený obecný závěr. ZFS na servery a i nadále md raid na stanice. Třeba bude za pár let situace jiná.

[Filip Jirsák]

To, že je něco klíčový případ pro vás, ještě neznamená, že je to klíčový případ pro btrfs a že je pro to btrfs ideální volba.

[dustin]

Proto jsem také ve svém příspěvku psal o svém pohledu na riskantní stav a svém rozhodnutí, viz výše. Každý nechť se zařídí dle svého.

[Jendа]

Takze kdyz budu mit 1000 serveru, budu muset mit o 1000 disku navic kvuli brtfs

Ne. Jenom nemůžeš dělat RAID1 přes 2 disky, ale přes 3 (pozor, to neznamená, že ztratíš dvě třetiny kapacity (a že by data byla fyzicky třikrát)). Což může být trochu k naštvání, pokud jsou to servery jako Sun Fire X2250, které mají defaultně dva sloty na disky ;).

[Filip Jirsák]

Zakladni myslenka RAID1 je takova, ze po vypadku disku vse funguje bezvypadkove, bez zasahu admina a hlavne RW jako by se nechumelilo. Produkce musi bezet, proto tam mam snad sakra RAID ne?

To máte dost zvláštní představu o RAIDu. Jednou budete velmi nemile překvapen, až vám třeba v RAID1 nebo RAID5 vypadne jeden disk, vy to necháte běžet dál,jako by se nechumelilo, a později vypadne další disk. Pokud „produkce musí běžet“, používá se např. replikace dat.

Btrfs RAID1 to zjevne nesplnuje

Na to jste přišel jak? Já bych spíš řekl, že děláte zjevně nesmyslné závěry z toho, že jeden člověk neumí vyměnit vadný disk v RAIDu.

[dustin]

A co by to mělo udělat jiného, než běžet dál (a zahájit synchronizaci spare disku) a správce bombardovat hláškami o problému, aby disk vyměnil co nejdříve? Zajímalo by mě, jaké servery spravuješ, kde se při výpadku disku v raidu migrují na jiný server a raid přepíná do read-only. Zní to zajímavě, ale zajímaly by mě konkrétní zkušenosti z praxe. Sekundární server s hot daty samozřejmě máme, ale při výpadku disku z raidu nepřehazujeme, to by muselo spadnout pole celé.

[Filip Jirsák]

Jste si jistý, že reagujete na správný příspěvek? Já nevím, co by to mělo dělat jiného – myslím si, že by to mělo dělat přesně to, co popisujete, a jak se to také chová. Různé úvahy o tom, jak se jim souborový systém po výpadku disku sám remountuje do degraded módu v read-only režimu tady psali jiní, ne já. O migraci dat na jiný server v okamžiku výpadku tu zase píšete vy.

Ještě jednou, RAID není žádná magická ochrana proti výpadkům disků. RAID umožňuje (mimo jiné) zmenšit následky výpadků disků. Když máte požadavek, že data musí být uložena alespoň na dvou discích, máte je uložena právě na dvou discích a jeden disk vám vypadne, nemůžete jet dál jakoby se nechumelilo, protože původní požadavek na dva disky v tom okamžiku není zajištěn. Existují ale i měkčí požadavky, třeba že data musí být vždy alespoň na dvou discích, s výjimkou případu, kdy jeden disk vypadne – pak musí okamžitě začít synchronizace na záložní disk. Tenhle požadavek ale vyžaduje, že v poli máte spare disk (což asi nebude efektivní řešení pro RAID1 se dvěma disky). A nebo ještě měkčí požadavek, jako to měl Vandrovnik, že může být pole degradované i po dobu, kdy se čeká na výměnu disku v servisu. Přičemž u těch variant, kdy je dočasně snížená redundance, se mohou dělat další opatření, třeba informovat uživatele nebo nemazat odjinud data, která se přenášejí na to pole.

To všechno jsou přípustné varianty, jenom to musí vždy správce řešit, nemůže se při výpadku disku tvářit, že se nic neděje.

[Michal]

Teda pohyboval jsem se v mnoha prostredich od male firmy az po enterprise ale na RAID1/5/10 byl vzdy jeden jediny pozadavek - aby to po vypadku disku jelo dal. Ty vase tvrde pozadavky nemel nikdo neb je pro ne RAID nevhodnym resenim. By me fakt interesovalo, kdo ma pozadavek na data ve dvou kopiich a resi to RAIDem tedy disky ve stejne lokaci postizitelne stejnou zivelnou pohromou, stejnym hardwarovym problemem (vadny zdroj co odpali cely zbytek pocitace, vadny radic zapisujici pseudonahodne hodnoty na disky,...), stejnym clovekem, stejnym sw problemem,...

Teda vlastne jo, v jedne nejmenovane firme si mysleli, ze kdyz maji data na RAID6 tak nemusi zalohovat. Doplatili na to.

[Filip Jirsák]

aby to po vypadku disku jelo dal

Což je ale podstatně jiný požadavek, než „aby to po výpadku disku jelo dál, jako by se nic nestalo“. Protože v tom vašem případě, kdy se bere v úvahu, že se něco stalo a pole není ve standardním režimu, se pravděpodobně hned vymění vadný disk za nový a začne resynchronizace pole. Takže doba, kdy pole nesplňuje ty tvrdé požadavky, se omezí „jen“ na dobu nutnou k resynchronizaci.

neb je pro ne RAID nevhodnym resenim

To už tady padlo několikrát, ale někteří si to nenechají vymluvit a pořád trvají na tom, že účelem RAIDu je hlavně nepřijít o data. Zjevně ta nejmenovaná firma s RAIDem 6, co nemusela zálohovat, má své následovníky – i tady v diskusi.

[dustin]

Ale houby, každý pochopí, že tím "jako by se nic nestalo" myslel vliv na chod aplikací. To dá rozum, že se musí disk urychleně vyměnit, řešíš tu nesmysly, nikdo tu nenavrhuje, aby se disk nevyměnil za jiný a nechalo se to běžet tak.

[Filip Jirsák]

Právě že takové požadavky tady byly – bez zásahu admina, jako by se nic nestalo.

Pokud je to běžná situace, že disk začne vykazovat chyby, normálně se přidá další disk, v btrfs se jím nahradí ten vadný a až doběhne rebalance, ten vadný se může odstranit. mount -o degraded je nutné použít jedině v případě, kdy příslušný disk v systému úplně chybí, nebo má vadný superblok.

[dustin]

Ale nebyly, to si jenom hraješ se slovíčky. Bez zásahu admina je myšleno, že to běží dál bez zásahu admina, to je přece jasné. Nikdo tu netvrdil, že se nemá disk vyměnit. A výměnou se myslí výměna, ne přidání dalšího a odebrání starého, až se to celé zasynchronizuje. To tam půjde admin dvakrát? Ve školní laborce možná jo, v reálném nasazení je to nesmysl.

[Filip Jirsák]

Běží to dál bez zásahu admina, admin tam jde jenom jednou po resynchronizaci a vymění vadný disk za nový spare disk.

[Max]

Já většinou na spare disky nejedu :). U společného storage spare mám, když mám servery plný SAS disků s hw raidem, tak to mám většinou řešeno tak, že mi v šuplíku leží od každého modelu jeden náhradní disk. Tzn., třeba 4 disky k hafec serverům.
Je to jednak z důvodu úspory (nemusím mít nakoupeno tolik disků) a jednak z důvodu, že pro spare disk už třeba nemám místo (třeba HP má většinou šasi pro 8x SAS a se 7x hdd se dělá blbě RAID10).
Vadné disky pak na pobočkách mění obyčejný user, který nemá s IT nic společného :).
To je jen příklad proti tvému idealismu se spare diskama :).
Zdar Max

[Filip Jirsák]

To je jen příklad proti tvému idealismu se spare diskama :).

To je problém příkladů, které popisuje Dustin. Na jedné straně je všechno ideální a vše se děje samo bez zásahu admina, na druhé straně je to ten nejhorší možný RAID se dvěma disky. Těžko pak uhodnout, zda řešíme, jak by to mělo fungovat co nejlépe, nebo zda řešíme alespoň nějaký RAID pro dva disky.

[Heron]

No já nevím, Murphy nikdy nespí a události se řadí tak, aby napáchaly co největší škodu. V klasických HW polích spare máme všude, jednak se tím o něco málo odloží nutnost výměny disku (ty to musíš udělat ASAP), ale taky už se nám stalo, že v RAID10 s 8 diskama během 1. měsíce odešly 4 disky a jednou dokonce dva v rozmezí hodiny (naštěstí z různých mirrorů). Pole s 12 disky v R10 jsme raději od počátku nechali další dva disky jako spare a dvě pozice volné. Už tak je dost stresu (jak je ostatně vidět i z tvého zápisku z práce), tak proč si ještě přidávat další s rychlou výměnou disků. (Takto si třeba dovolím nechat výměnu až na pracovní den a neřešíme to o víkendu. Kdyby byl degradované pole, tak bych si to na produkci teda nelajznul nechat tak.)

Apropos, zrovna řešíme jedno pole, kde není místo na spare. Ve stejném racku jsou sice i náhradní disky, ale stejně to ještě předěláme tak, aby se tam tem spare vlezl. Tohle byla chyba minulého kolegy (který už tady není a napáchal trochu víc problémů).

[MP]

Od toho mame v datacentru onsite support, ktery predpripraveny disk v racku vymeni

[Heron]

Jo, to my taky, ale pořád mi přijde, že spare disk se aktivuje trochu rychleji, než podpora.

[j]

A co budes delat, kdyz se na tebe ten onsite support vysere ...

[dustin]

Spare v nějaké "produkční" verzi brtfs?

[Filip Jirsák]

S btrfs je lepší používat všechny dostupné disky, zvýší se tím propustnost a sníží čas potřebný na resynchronizaci – místo „spare“ disku je pak potřeba mít na celém poli alespoň tolik volného místa, jaká je kapacita největšího disku. Ale jinak můžete samozřejmě i s btrfs používat opravdový spare disk – princip spare disku je v tom, že je to disk okamžitě připravený k použití, nemusí být použit automaticky, ale ručně na zásah admina. A nebo si to klidně můžete naskriptovat, že když nějaký disk začne podle S.M.A.R.T. vykazovat moc chyb, vyměníte ho automaticky.

[dustin]

Spare je standardně sdílený mezi více poli (což u btrfs asi nedává smysl, tam bude pole asi jedno, rozparcelované přes subvolumes). Pokud bych jej měl mít u jednoho raid1 a chtěl okamžité připravení - rovnou jej strčím jako další mirror disk toho raidu. Tak mi přijde, že je to u btrfs - spare není, protože se ve standardním provozu předpokládají alespoň 3 disky, co jsem z této diskuse pochopil...

[Filip Jirsák]

Trochu podrobněji to popsal třeba Heron v Chování při výpadku disku. Pokud chcete používat btrfs, doporučuji přečíst si celý jeho miniseriál.

[Jose]

Jeden by očakával že bude existovat něco jako "btrfs device rebuild", pokud ne, proč se tvářit že je to použitelnej fs ?

[Want]

Proč komentujete něco o čem víte kulové? Pohledejte krapet na netu. Třeba při tom natrefíte i na můj manuál, který je v češtině a jak pro blbce.

[k3dAR]

tak ja nevim, ale pokud manual pro blbce psal blbec, mam pocit ze to bude nejakej blbej filesystem pro blbce od blbcu co by opravdu pouzival jen blbec ;)

[Want]

Snadná pomoc - nepoužívat, a blbě neremcat.

[bigBRAMBOR]

tak by se dal shrnout ten tvuj návod?

[Aleš Kapica]

Tak by se dal shrnout jeho přístup. Já používám podle toho jestli se mi zdají dobré, nebo ne. A když hledám informace, je mi jedno co je autor zač. Důležité je pro mne, jestli tam najdu řešení problému co hledám.

Ovšem pokud si někdo hodnotí software na základě sympatií či antipatií, pak je lepší aby ho raději ani nepoužíval a neotravoval vzduch. Výblitků o tom jak něco stojí za prd, od lidí co nejsou schopni přečíst manuál, jsou na webu tuny.

[petr]

Protoze on to je za urcitych okolnosti pouzitelny fs. Treba kdyz mas 1 disk. Nebo kdyz si udelas mdraid a nad tim btrfs uvidi zase jenom 1 device, tak je to pouzitelny. Dokonce i vytvareni snapshotu funguje. A to ostatni co funguje/nefunguje je pry zdokumentovano a mas si to najit, precist vsechny mozne konstelace kdy neco nefunguje a dle toho se zaridit. Kdyz cekas ze se bude chovat fs dle navrhu a dle commandu ktere ti nabizi, pak musis pouzit jiny fs, tady je spousta ruznych podminek kdy se ti neco posere a vsichni o tom x let vi ale nikdo to jeste nefixnul.

[Aleš Kapica]

To si děláte srandu, že?

Jedinou výhodou Btrfs nad něčím jako je md raid je, že vás ochrání před nepěknými vlastnostmi md raidu a navíc umožní mnohem elegantnější snapshoty než LVM.

Aby dávalo Btrfs smysl, potřebuje být v raid1 a mít k dispozici více než dva disky – což je bohužel klíčový problém dnešních tenkých sraček, kterým se říká notebooky. Drtivá většina z mich to neumožňuje.

Já jsem vyřešil situaci tím, že mám v notebooku místo klasického 2,5 palcového disku interní řadič na dva SSD disky. A navíc bych mohl využít i slot kde mám jinak DVD mechaniku. Tam bych mohl píchnout v případě nutnosti další dva. Ale to nechci, protože čím víc nezálohovaných dat na notebooku, tím víc vám jich ukradou.

Ano. Dotazů proč to tak mám, jsem slyšel už nepočítaně, ale já zkrátka SSD diskům nevěřím, protože mám s nima špatné zkušenosti. Takhle pokud mi nějaký chcípne jenom vyměním jedno SSD za druhé, udělám rebalancing a jedu dál. Ten kdo to tak nemá, je odsouzen k tomu oželet soubory které nestihnul odzálohovat a podstoupit novou instalaci se vším všudy. A kdo si má pamatovat co všechno kdy a proč jsem si musel nainstalovat, nastavit a jak.

[Aleš Kapica]

Takže konkrétně. Jaké disky jsou v tom stroji? Jede ten stroj? Nebo to byl systémový disk a ten stroj nejede? Zřejmě asi ne, protože to by jinak nebyla k dispozici ta hláška.

stroj :~# cat /proc/partitions
…

Který z těch disků byl v tom Btrfs v raid1? Který je ten nový co chcete vrazit zpátky? Co nástroj btrfs, jaké má možnosti? Umožňuje vypsat status zařízení? Starší verze některé příkazy ještě neumí. Nejde tedy o problém Btrfs jako takového. V takovém případě bych doporučil zkompilovat si aktuální verzi nástrojů pro práci s Btrfs, nebo použít nějaké live distro (třeba System Rescue CD). Nevím jestli to víte, ale pro zjištěná statusu pro zařízení můžete použít i přímo cestu k zařízení. Nemusí to být nutně cesta na přípojný bod. Zkusil jste udělat ten příkaz s tím parametrem missing?

[vandrovnik]

Tak pro úplnost, jak jsem to vyřešil:

- na novém disku jsem vytvořil partition, na ní pomocí mdamd RAID1 ze dvou disků (nová partition a missing)

- mkfs.btrfs

- protože ten svazek byl použit jen jako archiv (každý den snapshot), vypsal jsem si do souboru seznam složek setříděný od nejstarší a pak použil:

cat /root/ar4 | while read Slozka; do
 rsync --no-whole-file --inplace --progress -avz --delete /archiv/$Slozka/ /mnt/a/aktualni/
 btrfs subvolume snapshot -r /mnt/a/aktualni/ /mnt/a/$Slozka
done

V /archiv byl stávající archiv namountovaný read-only, v /mnt/a je ten nový archiv.

- zrušil jsem původní archiv a jeho partition přidal do mdadm raidu

Asi by to šlo i příkazem btrfs send/receive, ale s tím nemám zkušenosti a nechtěl jsem riskovat, že zas narazím na nějakou léčku

Děkuju všem za rady, příspěvky a náměty.

KR

[Want]

Tak tohle harakiri jsem fakt nepochopil.

[vandrovnik]

A čemu na tom nerozumíte?

V původním archivu je asi 400 snapshotů - co den, to snapshot. A bylo potřeba to dostat na nový disk tak, aby to opět byly snapshoty, a aby místo na disku zabíralo jen to, co se mezi jednotlivými dny změnilo (využití COW).

[Aleš Kapica]

Čemu na tom nerozumím? Především tomu, proč místo normálního nahrazení disku postupem který jsem popsal o něco výš zbrkle stěhujete data do Btrfs v single modu nad md raid 1.

Neříkám že to nejde, ale proboha proč?! Pokud máte možnost do toho stroje strčit víc disků, tak jste měl jenom rozšířit to stávající Btrfs (namountované s parametrem degraded) o další zařízení, tak aby měl k dispozici víc než jeden disk, pak ho normálně namountovat - už bez parametru degraded, vyhodit co je ve stavu missing a poštvat na to ten balancing.

[vandrovnik]

Je to na serveru na druhém konci republiky, výměnu disků dělal kolega podle instrukcí na dálku, rezervní 6 TB disk se tam nikde nepovaloval, proto jsme se dohodli, že po dobu reklamace archiv poběží v degradovaném módu. Bohužel jsem nepředpokládal/nepřečetl si, že pak už ten disk přidat nepůjde.

[Aleš Kapica]

No teď už je to jedno. Tak jak jste to udělali, se to také dá používat. A konec konců, zpátky na raid1 se to dá přebalancovat vždycky. Jak jsem napsal už na jiném místě téhle diskuze, pro Btrfs v raid 1 je lepší stav když je k dispozici více disků, klidně o menší kapacitě, než když jsou jen dva o kapacitě velké.

[Michal]

Ponauceni pro priste ma nazev ZFS.

zpool replace nazevpoolu /dev/disk/by-id/id-vadneho-disku dev/disk/by-id/id-noveho-disku

a to je vse. Zadne vifikundace, zadne vypadky, zadne 80-ti prispevkove diskuze kolem reseni problemu tak banalne trivialnich, jako je vymena disku v RAID1.

[Aleš Kapica]

Víte co? Chytráky co píšou taková moudra a přitom pracují s úložištěm, které je nadupané diskama bych nejraději kopnul do prdele. Celá tahle diskuze se vede jen proto, že byl někdo škrt a myslel si, že vytrne celou storage dvěma diskama. Postav si ZFS pole nad dvěma disky, pak si dej jeden do háje a pak vynášej moudra. Neříkám že ZFS stojí za prd, má i svoje výhody, ale i nevýhody. Tak srovnávejte laskavě srovnatelné za srovnatelných HW podmínek.

Btrfs v raid 1 umožňuje seskládat pole ze všeho co máte po ruce a průběžně do něj přidávat nové disky, aniž byste museli řešit jak je který z nich velký. To pokud vím ZFS neumí a funguje stejně jako každý jiný pitomý md raid.

[dustin]

Právě jsem to vyzkoušel, po vytažení disku ze šuplíku dvoudiskový mirror zfs napíše:

status: One or more devices could not be used because the label is missing or
	invalid.  Sufficient replicas exist for the pool to continue
	functioning in a degraded state.

A samozřejmě filesystém jede dál. Proč by to nemělo fungovat?

Dvoudiskové raid1 (md raid, se zfs teprve začínáme) běžně používáme na pracovních stanicích kvůli úspoře času - když odejde disk, vymění se za nový a pracovník normálně pracuje dál, zatímco se mu to na pozadí synchronizuje. Zálohy samozřejmě jsou, ale proč to komplikovat, když stačí dva disky. To je přece úplně normální řešení, co je na tom špatně?

[Filip Jirsák]

A teď to samé zkuste s btrfs.

[dustin]

Očekával bych úplně to samé, i po případném rebootu.

[Jendа]

Zkusil jsem to a kupodivu to skončilo stejně jako tazateli s missing devices (1) exceeds the limit (0), writeable mount is not allowed; open_ctree failed.

/tmp # uname -a
Linux tatava 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux
/tmp # mkfs.btrfs -f -m raid1 -d raid1 /dev/loop5 /dev/loop6
btrfs-progs v4.12
See http://btrfs.wiki.kernel.org for more information.

Performing full device TRIM /dev/loop5 (476.84MiB) ...
Performing full device TRIM /dev/loop6 (476.84MiB) ...
Label:              (null)
UUID:               3638fdbe-8049-4d49-accc-d98b65dd9fff
Node size:          16384
Sector size:        4096
Filesystem size:    953.67MiB
Block group profiles:
  Data:             RAID1            64.00MiB
  Metadata:         RAID1            47.62MiB
  System:           RAID1             8.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  2
Devices:
   ID        SIZE  PATH
    1   476.84MiB  /dev/loop5
    2   476.84MiB  /dev/loop6

/tmp # mount /dev/loop5 /mnt/btrfs/
/tmp # echo ahoj > /mnt/btrfs/ble
/tmp # umount /mnt/btrfs 
/tmp # losetup -d /dev/loop6
/tmp # mount /dev/loop5 /mnt/btrfs/
mount: wrong fs type, bad option, bad superblock on /dev/loop5,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
[409621.818397] BTRFS info (device loop5): disk space caching is enabled
[409621.818408] BTRFS info (device loop5): has skinny extents
[409621.820543] BTRFS error (device loop5): failed to read chunk tree: -5
[409621.880963] BTRFS error (device loop5): open_ctree failed
/tmp # mount -o degraded /dev/loop5 /mnt/btrfs/
/tmp # dmesg -c
[409633.574482] BTRFS info (device loop5): allowing degraded mounts
[409633.574495] BTRFS info (device loop5): disk space caching is enabled
[409633.574500] BTRFS info (device loop5): has skinny extents
/tmp # echo ahoj2 > /mnt/btrfs/ble2
/tmp # umount /mnt/btrfs 
/tmp # mount -o degraded /dev/loop5 /mnt/btrfs/
/tmp # echo ahoj3 > /mnt/btrfs/ble3
/tmp # umount /mnt/btrfs 
/tmp # mount -o degraded /dev/loop5 /mnt/btrfs/
mount: wrong fs type, bad option, bad superblock on /dev/loop5,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
[409667.522866] BTRFS info (device loop5): allowing degraded mounts
[409667.522877] BTRFS info (device loop5): disk space caching is enabled
[409667.522881] BTRFS info (device loop5): has skinny extents
[409667.524987] BTRFS warning (device loop5): missing devices (1) exceeds the limit (0), writeable mount is not allowed
[409667.601637] BTRFS error (device loop5): open_ctree failed
/tmp # 

[Filip Jirsák]

Ne, vy jste zkusil něco úplně jiného. Dustin psal, že vytáhl disk ze šuplíku u přimountovaného souborového systému. Vidíte v jeho komentáři někde, že by odmountovával a zase přimountovával souborový systém?

[dustin]

Samozřejmě že jsem ten degradovaný zfs zkoušel opakovaně od/přimontovávat, abych nasimuloval třeba ten nečekaný korektní restart serveru, kterému nejde zabránit.

[sigma]

Hm, hm, a přesto bude řada lidí obhajovat, že to je tak správně.

Jasně, takové chování může být požadované. Ale jakýkoliv RAID1, se kterým jsem se zatím setkal (počínaje mdraid přes ZFS a desítky typů HW řadičů za posledních 20 let) se v základní konfiguraci chová jinak - prostě to běží s jednou kopií, a sype warningy. Akorát autoři BTRFS se rozhodli, že ve výchozím stavu budou uvažovat jiné požadavky na chování, než jak to dělá zbytek světa...

Jde to aspoň při vytvoření nějak nastavit, aby se to chovalo jako každý jiný RAID1? Tedy aby to po výpadku disku běželo dál po libovolném počtu rebootů, a při vložení nového čistého disku na stejnou pozici to začalo s resynchronizací (no, to už bych v linuxu chtěl asi moc)?

[Aleš Kapica]

Jde, pokud si opatchuješ jádro. Což je v podstatě odpověď i pro všechny, kterým se tohle chování u Btrfs nelíbí – prosaďte tu změnu v kernelu.

Tak jsem si vyzkoušel btrfs raid1:

#!/bin/sh
set -x
uname -a

dd if=/dev/zero of=disk1 bs=1 count=0 seek=1G
dd if=/dev/zero of=disk2 bs=1 count=0 seek=1G
losetup /dev/loop1 disk1
losetup /dev/loop2 disk2
mkfs.btrfs -f -m raid1 -d raid1 /dev/loop1 /dev/loop2
mkdir -p btrfsmnt
mount /dev/loop1 btrfsmnt
btrfs fi df btrfsmnt
btrfs fi show btrfsmnt
btrfs fi usage btrfsmnt
dd if=/dev/zero of=btrfsmnt/file1 bs=1M count=100
dd if=/dev/zero of=btrfsmnt/file2 bs=1M count=100
dd if=/dev/zero of=btrfsmnt/file3 bs=1M count=100
dd if=/dev/zero of=btrfsmnt/file4 bs=1M count=100
dd if=/dev/zero of=btrfsmnt/file5 bs=1M count=100
#dd if=/dev/zero of=btrfsmnt/file6 bs=1M count=100
btrfs fi df btrfsmnt
btrfs fi show btrfsmnt
btrfs fi usage btrfsmnt
btrfs balance start -f --full-balance btrfsmnt
dmesg | tail

s tímto výsledkem:

+ uname -a
Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux
+ dd if=/dev/zero of=disk1 bs=1 count=0 seek=1G
0+0 záznamů přečteno
0+0 záznamů zapsáno
0 bajtů zkopírováno, 0,00010714 s, 0,0 kB/s
+ dd if=/dev/zero of=disk2 bs=1 count=0 seek=1G
0+0 záznamů přečteno
0+0 záznamů zapsáno
0 bajtů zkopírováno, 9,4216e-05 s, 0,0 kB/s
+ losetup /dev/loop1 disk1
+ losetup /dev/loop2 disk2
+ mkfs.btrfs -f -m raid1 -d raid1 /dev/loop1 /dev/loop2
btrfs-progs v4.7.3
See http://btrfs.wiki.kernel.org for more information.

Performing full device TRIM (1.00GiB) ...
Performing full device TRIM (1.00GiB) ...
Label:              (null)
UUID:               
Node size:          16384
Sector size:        4096
Filesystem size:    2.00GiB
Block group profiles:
  Data:             RAID1           102.38MiB
  Metadata:         RAID1           102.38MiB
  System:           RAID1             8.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  2
Devices:
   ID        SIZE  PATH
    1     1.00GiB  /dev/loop1
    2     1.00GiB  /dev/loop2

+ mkdir -p btrfsmnt
+ mount /dev/loop1 btrfsmnt
+ btrfs fi df btrfsmnt
Data, RAID1: total=102.38MiB, used=128.00KiB
System, RAID1: total=8.00MiB, used=16.00KiB
Metadata, RAID1: total=102.38MiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B
+ btrfs fi show btrfsmnt
Label: none  uuid: 947f1aac-ffd3-46e4-89bd-5dc1a0110aa7
	Total devices 2 FS bytes used 256.00KiB
	devid    1 size 1.00GiB used 212.75MiB path /dev/loop1
	devid    2 size 1.00GiB used 212.75MiB path /dev/loop2

+ btrfs fi usage btrfsmnt
Overall:
    Device size:		   2.00GiB
    Device allocated:		 425.50MiB
    Device unallocated:		   1.58GiB
    Device missing:		     0.00B
    Used:			 512.00KiB
    Free (estimated):		 913.50MiB	(min: 913.50MiB)
    Data ratio:			      2.00
    Metadata ratio:		      2.00
    Global reserve:		  16.00MiB	(used: 0.00B)

Data,RAID1: Size:102.38MiB, Used:128.00KiB
   /dev/loop1	 102.38MiB
   /dev/loop2	 102.38MiB

Metadata,RAID1: Size:102.38MiB, Used:112.00KiB
   /dev/loop1	 102.38MiB
   /dev/loop2	 102.38MiB

System,RAID1: Size:8.00MiB, Used:16.00KiB
   /dev/loop1	   8.00MiB
   /dev/loop2	   8.00MiB

Unallocated:
   /dev/loop1	 811.25MiB
   /dev/loop2	 811.25MiB
+ dd if=/dev/zero of=btrfsmnt/file1 bs=1M count=100
100+0 záznamů přečteno
100+0 záznamů zapsáno
104857600 bajtů (105 MB, 100 MiB) zkopírováno, 0,0473304 s, 2,2 GB/s
+ dd if=/dev/zero of=btrfsmnt/file2 bs=1M count=100
100+0 záznamů přečteno
100+0 záznamů zapsáno
104857600 bajtů (105 MB, 100 MiB) zkopírováno, 0,045225 s, 2,3 GB/s
+ dd if=/dev/zero of=btrfsmnt/file3 bs=1M count=100
100+0 záznamů přečteno
100+0 záznamů zapsáno
104857600 bajtů (105 MB, 100 MiB) zkopírováno, 0,0449962 s, 2,3 GB/s
+ dd if=/dev/zero of=btrfsmnt/file4 bs=1M count=100
100+0 záznamů přečteno
100+0 záznamů zapsáno
104857600 bajtů (105 MB, 100 MiB) zkopírováno, 0,0486156 s, 2,2 GB/s
+ dd if=/dev/zero of=btrfsmnt/file5 bs=1M count=100
100+0 záznamů přečteno
100+0 záznamů zapsáno
104857600 bajtů (105 MB, 100 MiB) zkopírováno, 0,0406407 s, 2,6 GB/s
+ btrfs fi df btrfsmnt
Data, RAID1: total=518.38MiB, used=128.00KiB
System, RAID1: total=8.00MiB, used=16.00KiB
Metadata, RAID1: total=102.38MiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B
+ btrfs fi show btrfsmnt
Label: none  uuid: 947f1aac-ffd3-46e4-89bd-5dc1a0110aa7
	Total devices 2 FS bytes used 256.00KiB
	devid    1 size 1.00GiB used 628.75MiB path /dev/loop1
	devid    2 size 1.00GiB used 628.75MiB path /dev/loop2

+ btrfs fi usage btrfsmnt
Overall:
    Device size:		   2.00GiB
    Device allocated:		   1.23GiB
    Device unallocated:		 790.50MiB
    Device missing:		     0.00B
    Used:			 512.00KiB
    Free (estimated):		 913.50MiB	(min: 913.50MiB)
    Data ratio:			      2.00
    Metadata ratio:		      2.00
    Global reserve:		  16.00MiB	(used: 0.00B)

Data,RAID1: Size:518.38MiB, Used:128.00KiB
   /dev/loop1	 518.38MiB
   /dev/loop2	 518.38MiB

Metadata,RAID1: Size:102.38MiB, Used:112.00KiB
   /dev/loop1	 102.38MiB
   /dev/loop2	 102.38MiB

System,RAID1: Size:8.00MiB, Used:16.00KiB
   /dev/loop1	   8.00MiB
   /dev/loop2	   8.00MiB

Unallocated:
   /dev/loop1	 395.25MiB
   /dev/loop2	 395.25MiB
+ btrfs balance start -f --full-balance btrfsmnt
ERROR: error during balancing 'btrfsmnt': No space left on device
There may be more info in syslog - try dmesg | tail
+ dmesg
+ tail
[170304.296218] BTRFS info (device loop2): has skinny extents
[170304.296219] BTRFS info (device loop2): flagging fs with big metadata feature
[170304.297580] BTRFS info (device loop2): creating UUID tree
[170304.789212] BTRFS info (device loop2): relocating block group 462159872 flags 17
[170305.101215] BTRFS info (device loop2): relocating block group 136708096 flags 17
[170305.490432] BTRFS info (device loop2): relocating block group 29360128 flags 20
[170305.857469] BTRFS info (device loop2): found 6 extents
[170306.180689] BTRFS info (device loop2): relocating block group 20971520 flags 18
[170306.580826] BTRFS info (device loop2): found 1 extents
[170306.994521] BTRFS info (device loop2): 1 enospc errors during balance

Takže když by jeden disk odešel, já bych ho musel vyměnit a musel bych tudíž v nějakém okamžiku udělat btrfs balance, tak ho neudělám, protože btrfs raid1 už na to nemá místo při zaplnění asi na 50% své kapacity. Takže na raidu1 se dvěma disky, kde vědomě obětuji kapacitu celého disku, nevyužiju ani půlku toho jednoho disku, aniž bych se pak dostal do problémů?????

[Kandidat vied]

BTRFS s RAID1 nad 2 diskami je koledovanie si o velky pruser... RAID1 mostly OK Needs at least two available devices always. Can get stuck in irreversible read-only mode if only one device is present.

Díky kandidáte.

Ale ten můj příklad má pořád ještě dva funkční disky v raidu. A přesto při zaplnění asi tak na 50% nedokáže provést balance.

[Filip Jirsák]

musel bych tudíž v nějakém okamžiku udělat btrfs balance

Proč?

tak ho neudělám, protože btrfs raid1 už na to nemá místo při zaplnění asi na 50% své kapacity

Což jste si ale způsobil sám tím, že jste požadoval rebalancovat rovnou celý disk a ještě jste btrfs řekl, že vás před tím nemá varovat. Je vždycky podezřelé, když někdo chce dokázat, jak nějaký nástroj dělá něco špatně, a při tom vypíná varování toho nástroje.

OK. Tak tedy:

#btrfs balance btrfsmnt
WARNING:

        Full balance without filters requested. This operation is very
        intense and takes potentially very long. It is recommended to
        use the balance filters to narrow down the balanced data.
        Use 'btrfs balance start --full-balance' option to skip this
        warning. The operation will start in 10 seconds.
        Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting balance without any filters.
ERROR: error during balancing 'btrfsmnt': No space left on device
There may be more info in syslog - try dmesg | tail

To jsem si fakt pomohl.

[Filip Jirsák]

OK. Tak tedy:

#btrfs balance btrfsmnt

Připadá vám, že tohle je vytažení disku ze šuplíku?

Po případné výměně disku nemusím balance udělat?

Nemusíte. Prostě jenom btrfs řeknete, který disk má vyměnit za který.

btrfs replace start 2 /dev/sdc /mnt

OK. Díky.

Jo, ještě tohle:

musel bych tudíž v nějakém okamžiku udělat btrfs balance

Proč?

Po případné výměně disku nemusím balance udělat?

[Aleš Kapica]

Myslím že ne. Měl by stačit scrub. Při balancování se přežonglují extenty tak, aby byly po všech discích rozhozeny rovnoměrně, kdežto když se spustí scrub, jen doplní chybějící repliku.

[lertimir]

Jen poznámku. Se zájmem sleduji diskusi, ale vzhledem k tomu že nikde btrfs RAID nemám pouze ppřimý btrfs na discích tak diskuse je možná pohled do budoucna. ale k balanci. To co se mi vypláci je balancovat postupně

btrfs balance start -dusage=10
btrfs balance start -dusage=30
btrfs balance start -musage=10
btrfs balance start -musage=30

mi přežongluje část extentů a každý příkaz je rychlý a na konci je zase konzistentní stav FS. Přenese konzistentní stav do jiného konzistentního stavu.

[karlik]

Tak po přečtení celé debaty jsem konečně pochopil kauzu Btrfs a podpora Red Hat.

Nečekal jsem, že to bude až takový nedodělek.

[Filip Jirsák]

V tom případě jste nic nepochopil. Ani tu diskusi, ani postoj RedHatu. V případu RedHat a btrfs jde o to, že má RedHat problém s backportováním změn. Btrfs se rychle vyvíjí a RedHat nemá kapacitu na to backportovat všechny změny do svých „stabilních“ verzí, tak se rozhodli zatím obětovat btrfs.

[karlik]

Přesně tak.

Btrfs není stabilní a mění se "pod rukama" tak rychle, že RedHat není schopný garantovat stabilitu/podporu tohoto produktu.

Nejedná se o chyby, ty se dají dát do "readme", jde o to, že co platilo před hodinou už teď nemusí být pravda (viz i tato debata).

[Filip Jirsák]

To je zvláštní druh humoru, napsat „přesně tak“ a pak napsat opak. Tak ještě jednou – nejde o nějakou stabilitu nebo podporu btrfs, jde o to, že RedHat nemá dostatek kapacit na backportování změn v btrfs.

[dustin]

Z diskuse https://news.ycombinator.com/item?id=14907771, které se účastní i bývalí vývojáři redhatu, těch důvodů může být víc:

RH má tým specialistů na XFS a nepodařilo se mu sehnat vývojáře na btrfs, kteří by byli ochotni pro RH pracovat https://news.ycombinator.com/item?id=14910150.

Zdaleka nejde jen o backporty, ale i vlastní vývoj, protože hlavní přispěvatel btrfs Facebook míří svým směrem, který nemusí odpovídat potřebám klientů RH (kteří údajně o btrfs v této fázi až tak moc zájem neprojevují) https://news.ycombinator.com/item?id=14915666 .

Odstraněním backportovaného btrfs z redhatího kernelu může RH tlačit na Oracle (který údajně na svém Unbreakable Linuxu s redhatím jádrem btrfs klientům podporuje), aby místo pracného a drahého backportování btrfs (které už za něj nebude dělat RH) uvolnil ZFS pod GPL licencí a to se tak mohlo legálně dostat do kernelu https://news.ycombinator.com/item?id=14911843.

Je tam toho víc, zajímavá diskuse.

[Aleš Kapica]

RH má tým specialistů na XFS a nepodařilo se mu sehnat vývojáře na btrfs, kteří by byli ochotni pro RH pracovat

Toto je podle mě informace hodná zamyšlení. Stejně jako ty následující. Nevypovídá to totiž nic o Btrfs jako takovém, jako spíš o tom, že jde především o "politickou" záležitost. Red Hat potřebuje vydělávat a jeho klienti nechtějí Btrfs ale ZFS, které však nemůže z licenčních důvodů použít. A proč chtějí jeho klienti radši ZFS? K tomu stačí přečíst tuhle diskuzi.

[dustin]

Nevypovídá to totiž nic o Btrfs jako takovém, jako spíš o tom, že jde především o "politickou" záležitost.

Vypovídá i o tom, že na btrfs je ještě potřeba spoustu práce, aby to klienti RH chtěli.

[trekker.dk]

A hlavně aby jim to RH byl ochoten nabídnout jako "enterprise" věc.

[Filip Jirsák]

Ano, ale nejde o vlastnosti/chyby btrfs, ale o kapacitu vývojářů. Vítám to, že se RedHat snaží některé vlastnosti btrfs dostat do XFS – bude jedině dobře, když těch moderních FS bude víc. Navíc první generace průkopníků často nepřežije, protože sice přijdou s něčím novým, ale zároveň se udělá spousta chyb. U druhé generace se už ví, o co je zájem a jak se toho dá docílit, ale zároveň se můžeme vyvarovat těch chyb.

místo pracného a drahého backportování btrfs (které už za něj nebude dělat RH)

Je otázka, zda to bude na Oracle platit, zvlášť když je čím dál jasnější, že backportování „oprav“ je neudržitelné. Zejména ve světě cloudů, na který se Oracle zaměřuje.

[Heron]

Zkuste si totéž při nějaké normální velikosti disků. Btrfs má velikost alokační skupiny 1GB. Když mu (jistě schválně ) vytvoříte 1G disky, tak po zapsání dat má volných přesně 0 alokačních skupin. Tudíž je nemá kam zkopírovat při rebalance. Teoreticky by stačilo mít jednu skupinu volnou, ovšem v normálním provozu je více než vhodné mít toho místa o něco víc. Dřív udávané pravidlo plnit fs do 80% podle mě platí stále. Nebo ještě lépe jak píše Aleš.

[Heron]

Mno, tak jsem si to zkusil, zda se po letech něco nezměnilo a chová se to (až na nutnost umount) pěkně:

• 5x 600GB disk, btrfs od počátku raid1

mkfs.btrfs -d raid1 -m raid1 /dev/sd[b-f]

• Nějaký data, ať se má co syncovat

for i in `seq 1 100` ; do dd if=/dev/urandom of=$i bs=1M count=10 ; done

• poweroff vmka, odstranění disku, poweron
• mount jako degraded, připojilo se přirozeně jako rw

btrfs device delete missing /mnt/b

dmesg:
[   43.570533] BTRFS warning (device sdb): devid 5 uuid eca33d32-b4cb-4921-9d9b-f491b4f511fc is missing
[   95.389454] BTRFS info (device sdb): relocating block group 1103101952 flags data|raid1
[  109.919063] BTRFS info (device sdb): found 100 extents
[  115.764859] BTRFS info (device sdb): found 100 extents
[  115.780390] BTRFS info (device sdb): relocating block group 20971520 flags system|raid1
[  115.802630] BTRFS info (device sdb): found 1 extents
[  115.825904] BTRFS info (device sdb): device deleted: missing

• Co je fajn, a nejsem si jistej, zda to dělal i v minulosti (fakt si na to nepamatuju), že přímo během delete missing to duplikuje data, co byla na tom zařízení. Takže po doběhnutí delete missing máte opět konzistentní raid1. Během operace delete lze fs normálně používat.
• Potom umount, mount normálně.

Jak jsem psal už v tom odkazovaném článku, tak nutnost umount je prostě divná. Chová se to velmi rozumně a je škoda, že to nemá hotswap vadného disku. Klidně by se to mohlo chovat tak, že po výpadku zařízení to zmenší dostupnou velikost (stejně jako při device delete za normálního stavu) a automaticky to dosyncuje data.

Test na deb testing, kernel 4.12, btrfs tools 4.12-1.

[dustin]

Takže to není RAID 1, ale RAID 1E.

[Heron]

Ani bych neřekl. Btrfs v režimu raid1 zapisuje data na dvě (libovolná) disková zařízení nějakých chytřejších roundrobinem s přihlédnutí na zaplněnost daných zařízení.

Na té wikině je to pořád starý způsob vidění, stejně velké bloky dat, zápis na disky za sebou apod. BTRFS po x letech používání a výměně několika různě velkých disků bude mít ta data rozmístěna hodně chaoticky (stále ale ve dvou kopiích na dvou různých zařízeních).

Navíc ani neplatí "if drives of different sizes are used, only the portions equaling to the size of smallest member are utilized on each drive". Když jsem kdysi přecházel s 300GB disků na 1TB, tak ochotně tři 300GB disky mirroroval vůči jednomu 1TB. Místo rozhodně není omezené velikostí nejmenšího zařízení.

[Aleš Kapica]

Místo rozhodně není omezené velikostí nejmenšího zařízení.

Přesně tak. Moje domácí pole je složené ze 2x 2TB 2.5, 2x 2TB 3.5 a 2x 4TB 3.5 SSHD. Ty SSHD disky jsem použil jen proto, že pro ně nebylo v práci jiné využití – byl to pokus a měli jsme s nimi velmi špatnou zkušenost. Proto jsme je vyřadili. Na druhou stranu, škoda nevyužít jejich kapacitu než úplně chcípnou. Protože byly tři, jeden se mi válí pro případ, že by jeden náhle umřel. Pole je zaplněné cca z poloviny, takže když jeden ten 4TB disk náhle umře, tak se nic nestane. Data se rozloží na ty ostatní.

Do budoucna však se 3.5 palcovými rotačními disky vůbec nepočítám. Jsou velké, hlučné a žerou. Jak už jsem zmiňoval jinde, mám v bedně šuplíkový box na 12x 2.5 palcové SATA (SAS) disky. Zatím to není nutná investice, plánuji nahrazovat jen chcíplé disky. A pokud to bude nutné, přikoupím řadič a oživím i další šuplíčky.

[trekker.dk]

Na druhou stranu RAID1 by měl mirrorovat na všechna disková zařízení v tom poli, ne?

[vandrovnik]

Tohle myslím btrfs neumí - dává to vždy jen na dvě zařízení, což je jeden z důvodů, proč jsem btrfs pro nic jiného než archiv se snapshoty nepoužil (nerad bych zažil, že jeden disk odejde a druhý s těmi samými daty vzápětí). Mdadm umí raid 1 na víc zařízení, dokonce jde nastavit, že některé jsou "jen" pro zápis (takže čtení dělá přednostně z ostatních - SSD...), ale zase má holt jiné nevýhody.

[j]

A co myslis ze se stane kdyz ti odejdou dva disky v HW R1? Zeby ... R1 na vic zarizeni je totalni kravinium. Laskave si uvedom, ze raid neni zaloha, a neni a nikdy nebyl urcen k tomu, aby neztratil data (zcela libovolnej raid). Je a vzdy byl urcen k tomu, aby pri vypadku nekterych komponent fungoval dal.

Tim ze budes neco replikovat na 10 disku spolehlivost provozu nijak zasadne nezvednes, spis presne naopak.

[dustin]

?? RAID1 mirror přes 3 a více disků nemá větší spolehlivost než přes 2? Jak jsi na to přišel?

Nikdo tady o raidu jako náhradě záloh nemluvil.

[Aleš Kapica]

Pokud vím, tak MD RAID1 přes více disků má benefit v tom, že má rychlejší čtení, protože může data načítat z více disků současně, ale to více zase pomalejší zápis, protože to zdržuje ta replikace.

Pokud je určen pro zálohy, tak pak záleží dost hodně na tom, co a jak zálohuje. Pokud je nad ním Btrfs, které se snapshotuje, je to v pohodě, ale u FS co neumí snapshoty se můžete hravě dostat do situace, že vám bude 24 hodin na zálohu málo.

[dustin]

Zdroják md raidu jsem nestudoval, ale obecná "moudra", která už pár let poletují po netu:

Zápis - disky jedou současně, takže se čeká na nejpomalejší. Samozřejmě ty disky mohou být i součástí jiného pole (jiná partišna), o to se to zpomaluje.

Čtení - Jeden požadavek jde na jeden disk, ovladač si vybírá, který dle jeho názoru má nejblíže čtecí hlavičku požadovanému místu. A pak to nestripuje, takže jede rychlostí jednoho disku. Pokud však současně přijde další požadavek, probíhá výběr znovu a je dost pravděpodobné, že se vybere jiný disk. Takže zvládá více současných čtení.

Mně osobně rychlost u raid1 nepálí, používám jej kvůli redundanci - kontinuitě. Když mám 4 disky v raid1, mohou mi 3 umřít a pořád ještě žiju... Potřebuju-li rychlost, použiju ssd. Žádný raid z mechanických HDD se mu nijak nepřiblíží.

Ad zálohování - nevím, jak to souvisí s raidem. Samozřejmě že jsou snapshoty v podání zfs či btrfs při zálohování obrovská výhoda. Jak na straně zálohovaného stroje (bez nich vůbec nelze udělat konzistentní zálohu), tak i na straně zálohovacího serveru (když se inkrementální zálohy uloží jen jako další snapshot přes send/receive).

Ale to jsou úplně normální samozřejmé věci, které všichni dávno víme.

[vandrovnik]

Raid 1, který zrcadlí totéž na 3 disky, samozřejmě z principu bude spolehlivější, než když využívá disky 2.

Berte to třeba tak, že třetí disk je jako by spare disk, akorát že se pak nemusí čekat, než se na něj data nakopírují (a přitom se modlit, že zvýšená zátěž nepošle do kopru i ten přeživší disk).

[Max]

Tak jo, máme tu patch v aktuálním kernelu 4.14, cituji :

BTRFS : Allow a degraded read-write mount if all the raid profile constraints are met [zdroj]

Zdar Max

[izidor]

No je to nejake divne, viz commit.

With this patch, we can mount in the following case:
 # mkfs.btrfs -f -m raid1 -d single /dev/sdb /dev/sdc
 # wipefs -a /dev/sdc
 # mount /dev/sdb /mnt/btrfs -o degraded
 As the single data chunk is only on sdb, so it's OK to mount as
 degraded, as missing one device is OK for RAID1.

But still fail in the following case as expected:
 # mkfs.btrfs -f -m raid1 -d single /dev/sdb /dev/sdc
 # wipefs -a /dev/sdb
 # mount /dev/sdc /mnt/btrfs -o degraded
 As the data chunk is only in sdb, so it's not OK to mount it as
 degraded.

takze kdyz udelam wipe na sdc, tak sdb primountovat muzu. Ale kdyz udelam wipe na sdb, tak sdc primountovat nemuzu? Co to je za blbost?

No a jestli bude data chunk na obou, tak by to snad mohlo jít namountovat, ne?

 # mkfs.btrfs -f -m raid1 -d raid1 /dev/sdb /dev/sdc
 # wipefs -a /dev/sdb
 # mount /dev/sdc /mnt/btrfs -o degraded

[Max]

Co je na tom divného? Ty jsi tím příkazem na formátování řekl, že nechceš kopii dat (-d single), když se ti nedělá jejich kopie, tak je myslím jasné, že si nemůžeš jakýkoli disk libovolně připojovat v degradovaném režimu, ale jen ten, kde ty data fyzicky jsou.
Parametrem "-m" se definuje, jak se má btrfs chovat k metadatům, což v tom příkladě "-m raid1" znamená, že se raid1 uplatňuje jen na metadata. Pokud chceš mít něco jako mdadm raid1, tak bych asi sáhl po něčem jako :

mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdc

Pak by jsi teoreticky mohl připojovat v degradovaném režimu oba disky.
Aspoň tak to chápu z manuálových stránek.
Zdar Max

[vandrovnik]

Hurá!