Dotaz: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování

[lertimir]

Rozšiřuji si btrfs RAID1 nad 2 disky od další 2. provedl jsem následující akce.

1. Uklidil, vyprázdnil disky, odmountoval, zkontroloval, že jsou odmountované. ve df se nic nezobrazoval a mount adresáře byly prázdné.
2. Pomocí btrfs device add device mount-point-raidu jsem je do raidu přidal
3. Nyní jede btrfs balance. A pojede ještě dlouho protože se balancuje pár TB

Mezi tím jsem zrušil položky v /dev/fstab které původně mountovaly disky, které jsem přidával do RAID1. A následně jsem chtěl zrušit adresáře, do nichž byly ty disky připojovány. A z překvapením jsem zjistil, že jsou plné, a že je do nich vlastně namountovaná struktura btrfs raidu ještě jednou (dvakrát). Pokud si vypíšu df tak je výsledek "jak si představuji že by měl být" tedy RAID je připojen pouze do svého standardního bodu. Nicméně příkaz mount mi vypíše tuto skutečnou situaci, tedy že RAID je připojen do všech třech adresářů. Dokonce mount tam připojuje ani ne ty disky, které tam byly připojeny původně, ale původní disk ze kterého jsem RAID stavěl tedy nejdříve připojení jednoho disku s konverzí btrfs na RAID.

Ptám se jestli nevíte, proč to takto dopadlo? Jak dojede balance tak systém přebootnu a pak si myslím že vše bude jak má být stejně jako ten první pridávaný disky tak již nikde není připojen, ted na to samozřejmě nebudu sahat. Připadá mi že někde v tabulce zůstalo připojení i když jsem disky odmountoval.

Odpovědi

[multi]

Asi jsi btrfs neodmountoval. Tyto vsechny zmeny se daji a delaji za chodu.

Mozna v bode 2. se disk pripojil...

[Aleš Kapica]

Snažím se analyzovat tvé sdělení a přijde mi, že panikaříš zbytečně. Bohužel nemám křišťálovou kouli abych se podíval jak vypadala situace předtím, a jak vypadá teď.

Nicméně příkaz mount mi vypíše tuto skutečnou situaci, tedy že RAID je připojen do všech třech adresářů.

Každopádně pokud používáš subvolume, tak je úplně jasné že se zobrazí ve všech případech jedno a to samé zařízení. Rozhodující je totiž položka subvol v závorce.

Dokonce mount tam připojuje ani ne ty disky, které tam byly připojeny původně, ale původní disk ze kterého jsem RAID stavěl tedy nejdříve připojení jednoho disku s konverzí btrfs na RAID.

Tohle jsem nebyl schopen dešifrovat. Pokud jsi měl Btrfs v raid1, do kterého jsi přidal další dva disky, tak se nic nemění. Vždy uvidíš v mountu jen ten disk, který je aktuálně první v seznamu. I kdybys to Btrfs nakrásně připojoval přes libovolný z disků co ho tvoří.

[lertimir]

Tak jsem si to znovu zkusil a patrně proběhl automout.

[Aleš Kapica]

No. Jo. Takové obskurnosti, jako automount nepoužívám. Ona každá automatika má své meze.

[lertimir]

já si myslel, že to také nepoužívám.

[Aleš Kapica]

Důležitý je výsledek. Rozbilo to něco? Nebo vše dopadlo ok?

Jinak bych zde ještě poznamenal na téma nedávné diskuze o zaplácnutí Btrfs na 100%.

Kamarádka předevčírem zazmatkovala a když jí Virtualbox oznámil že je na disku málo místa, tak to dorazila tím, že chtěla udělat nový snapshot.

Takže mi volala o pomoc. Nejdřív podle mých instrukcí udělala truncate na nějaký starý log. Tím získala manipulační prostor. Odmazala logy, ale na spuštění Virtualboxu to bylo stále málo. Měla smůlu, že jsem byl zrovna na cestě k zubaři, tak musela počkat. Přihlásil jsem se pak vzdáleně přes telefon, zastavil systemd-journal.d, odmazal 1,5 GB logů co tam měl. Pak jsem promazal starší snapshoty a vyčaroval tím cca 70GB volného místa. Poté jsem udělal pro jistotu snapshoty aktuálního stavu, a kouknul na ten Virtualbox. Tam byl celý problém v tom, že nová verze knfiguráku vbox měla nulovou velikost. Překopíroval jsem tedy verzi s příponou vbox-prev. A vše normálně najelo. Problém byl vyřešen a kamarádka už pochopila, proč má smysl mít na zálohy externí velkokapacitní storage.

[lertimir]

Vše je OK. Nic se nestalo.

[Peter Golis]

1,5 GB logů

To by ma zaujímalo ako sa takéto niečo dá dosiahnuť.

[Aleš Kapica]

Ubuntu + systemd a půl roku nepřetržitého provozu.

Ale taky nevím. Nezkoumal jsem je. Jenom jsem na webu zaregistroval, že to není nenormální.

[lertimir]

no třeba muj journal má 4.1G

ll /var/log/journal/36045237ff4d4f07a6169708d88c9648 
celkem 4,1G
-rw-r-----+ 1 root systemd-journal  80M 18. lis 06.56 system@dc444159ca37456fb98a938af1818d8d-0000000000000001-00057a57eefa656c.journal
-rw-r-----+ 1 root systemd-journal  64M 22. lis 19.32 system@dc444159ca37456fb98a938af1818d8d-00000000000343dc-00057aea0fdd3d4c.journal
-rw-r-----+ 1 root systemd-journal  64M  2. pro 20.26 system@dc444159ca37456fb98a938af1818d8d-0000000000070740-00057b45182e415a.journal
-rw-r-----+ 1 root systemd-journal  96M 11. říj 00.57 system@fd1690ad8e054e3791c404c5676028d8-00000000000c8b66-0005771dd7c1eab9.journal
-rw-r-----+ 1 root systemd-journal 104M 25. říj 01.09 system@fd1690ad8e054e3791c404c5676028d8-00000000000ff2ae-000577e7cbd375d2.journal
-rw-r-----+ 1 root systemd-journal 8,0M  3. zář 17.16 system@fd1690ad8e054e3791c404c5676028d8-0000000000000001-000574e99add22a8.journal
-rw-r-----+ 1 root systemd-journal 8,0M  7. zář 00.41 system@fd1690ad8e054e3791c404c5676028d8-0000000000019066-000574f912f817e4.journal
-rw-r-----+ 1 root systemd-journal  40M 19. zář 11.38 system@fd1690ad8e054e3791c404c5676028d8-0000000000032276-0005753b9796323c.journal
-rw-r-----+ 1 root systemd-journal 8,0M 22. zář 00.29 system@fd1690ad8e054e3791c404c5676028d8-0000000000059405-0005763b2607ec0b.journal
-rw-r-----+ 1 root systemd-journal  40M 26. zář 22.53 system@fd1690ad8e054e3791c404c5676028d8-0000000000078618-0005766d70a6b597.journal
-rw-r-----+ 1 root systemd-journal  56M  1. říj 00.02 system@fd1690ad8e054e3791c404c5676028d8-000000000009d26c-000576cc6c1d1be6.journal
-rw-r-----+ 1 root systemd-journal  72M  3. lis 05.55 system@fd1690ad8e054e3791c404c5676028d8-0000000000136d71-0005790194ee8b68.journal
-rw-r-----+ 1 root systemd-journal  40M  8. lis 01.56 system@fd1690ad8e054e3791c404c5676028d8-00000000001681b9-000579bb7a4877c6.journal
-rw-r-----+ 1 root systemd-journal  40M 29. čec 14.24 system@f92e638f402643ff9b7d4bbc6e7d0c10-0000000000000001-00056fa7611a0a7f.journal
-rw-r-----+ 1 root systemd-journal 8,0M 29. čec 14.24 system@f92e638f402643ff9b7d4bbc6e7d0c10-0000000000025e79-000572226b9bbc74.journal
-rw-r-----+ 1 root systemd-journal 8,0M 29. čec 14.32 system@f92e638f402643ff9b7d4bbc6e7d0c10-000000000002602a-000572226c28b0d5.journal
-rw-r-----+ 1 root systemd-journal  24M 23. srp 18.46 system@f92e638f402643ff9b7d4bbc6e7d0c10-0000000000026073-000572228a966906.journal
-rw-r-----+ 1 root systemd-journal  16M 29. srp 01.06 system@f92e638f402643ff9b7d4bbc6e7d0c10-0000000000049f3a-0005741d1eacfa0f.journal
-rw-r-----+ 1 root systemd-journal  32M 24. led 09.48 system.journal
-rw-r-----+ 1 root systemd-journal  24M 13. čen  2018 system@00056e8bb5ccdbc2-b8da946c5af0a7e5.journal~
-rw-r-----+ 1 root systemd-journal  40M 28. čen  2018 system@00056fa761131c52-a71b3a710c4da8a4.journal~
-rw-r-----+ 1 root systemd-journal  24M 11. lis 00.36 system@00057a57eeec0075-92342c4210948841.journal~
-rw-r-----+ 1 root systemd-journal  24M  5. pro 15.53 system@00057c478a94970d-4b4dc7dd99328518.journal~
-rw-r-----+ 1 root systemd-journal  24M 14. led 21.55 system@00057f71427a9f6a-3ec3d505a946586c.journal~
-rw-r-----+ 1 root systemd-journal  16M  2. zář 22.52 system@000574e99adef0ed-6b725eeeecd78ab8.journal~
-rw-r-----+ 1 root systemd-journal 8,0M 18. zář 08.46 system@059c807f1cfe438eae584cc30b332ad7-0000000000000001-0005761fa4e1cf69.journal
-rw-r-----+ 1 root systemd-journal 8,0M 29. kvě  2018 system@2ff953404a9d4bcd8ec860345ffa0fa4-000000000020d5c1-00056d2191fb1724.journal
-rw-r-----+ 1 root systemd-journal 104M 17. pro 13.25 system@47e81a4605014f6ca1a047e5449bc470-00000000000a4188-00057c566c919b3e.journal
-rw-r-----+ 1 root systemd-journal  40M  2. led 19.58 system@47e81a4605014f6ca1a047e5449bc470-00000000000d98b1-00057d36e282610c.journal
-rw-r-----+ 1 root systemd-journal  24M  7. led 00.42 system@47e81a4605014f6ca1a047e5449bc470-00000000000ed922-00057e7e39d38fc0.journal
-rw-r-----+ 1 root systemd-journal  48M 11. led 23.04 system@47e81a4605014f6ca1a047e5449bc470-00000000000f95e6-00057ed2abb9ada7.journal
-rw-r-----+ 1 root systemd-journal  16M  6. pro 09.38 system@47e81a4605014f6ca1a047e5449bc470-0000000000000001-00057c478a92ab3f.journal
-rw-r-----+ 1 root systemd-journal  24M 16. led 08.02 system@56e41f92bc9d484aa0b193d2e7ae543f-0000000000000001-00057f7142789a74.journal
-rw-r-----+ 1 root systemd-journal  40M 21. led 02.19 system@56e41f92bc9d484aa0b193d2e7ae543f-000000000013d2fd-00057f8ddb1489dc.journal
-rw-r-----+ 1 root systemd-journal  24M 22. led 19.17 system@56e41f92bc9d484aa0b193d2e7ae543f-00000000001649fb-00057feda712eb5c.journal
-rw-r-----+ 1 root systemd-journal 128M 11. říj 00.57 user-1000@a36fdab0f66245f286577d6376b59bd2-00000000000c8b62-0005771dd70dd881.journal
-rw-r-----+ 1 root systemd-journal 128M 25. říj 01.09 user-1000@a36fdab0f66245f286577d6376b59bd2-00000000000fef14-000577e7c914da48.journal
-rw-r-----+ 1 root systemd-journal 128M  3. zář 17.19 user-1000@a36fdab0f66245f286577d6376b59bd2-0000000000000515-000574e9a14662a2.journal
-rw-r-----+ 1 root systemd-journal 128M  7. zář 00.41 user-1000@a36fdab0f66245f286577d6376b59bd2-0000000000019061-000574f912c0fa59.journal
-rw-r-----+ 1 root systemd-journal 128M 19. zář 17.31 user-1000@a36fdab0f66245f286577d6376b59bd2-000000000003204e-0005753b9719f0dc.journal
-rw-r-----+ 1 root systemd-journal 128M 22. zář 01.06 user-1000@a36fdab0f66245f286577d6376b59bd2-000000000005937f-0005763b1a95b133.journal
-rw-r-----+ 1 root systemd-journal 128M 26. zář 22.53 user-1000@a36fdab0f66245f286577d6376b59bd2-0000000000076e2b-00057669b09586c6.journal
-rw-r-----+ 1 root systemd-journal 128M  1. říj 00.02 user-1000@a36fdab0f66245f286577d6376b59bd2-000000000009d262-000576cc697b9927.journal
-rw-r-----+ 1 root systemd-journal 128M  3. lis 05.55 user-1000@a36fdab0f66245f286577d6376b59bd2-0000000000136d3c-00057901934203cb.journal
-rw-r-----+ 1 root systemd-journal 128M  8. lis 01.56 user-1000@a36fdab0f66245f286577d6376b59bd2-00000000001681b2-000579bb777f7e9c.journal
-rw-r-----+ 1 root systemd-journal  16M 24. led 09.48 user-1000.journal
-rw-r-----+ 1 root systemd-journal 8,0M 30. kvě  2018 user-1000@00056d71c3e5010a-9244d530ac72b235.journal~
-rw-r-----+ 1 root systemd-journal  72M 13. čen  2018 user-1000@00056e8bcc78b0ef-926841aba97f2f51.journal~
-rw-r-----+ 1 root systemd-journal  64M 28. čen  2018 user-1000@00056fa7611d598b-c14d3b6927ce211e.journal~
-rw-r-----+ 1 root systemd-journal  80M 20. čen  2018 user-1000@00056f165f907c80-283c2a779c53f528.journal~
-rw-r-----+ 1 root systemd-journal  72M 11. lis 00.36 user-1000@00057a57eeff5d47-f56c6ede72021fb6.journal~
-rw-r-----+ 1 root systemd-journal  48M  2. zář 22.54 user-1000@000574e9a146d791-ad021424e9d9c6b7.journal~
-rw-r-----+ 1 root systemd-journal 128M 17. pro 13.25 user-1000@188c9b557c0a4359ba0ccaa9e6a31e2b-00000000000a4183-00057c566bb408f3.journal
-rw-r-----+ 1 root systemd-journal 128M 11. led 23.04 user-1000@188c9b557c0a4359ba0ccaa9e6a31e2b-00000000000d98a5-00057d36e08ed3ba.journal
-rw-r-----+ 1 root systemd-journal 128M 18. lis 06.56 user-1000@188c9b557c0a4359ba0ccaa9e6a31e2b-0000000000000025-00057a57eefa9553.journal
-rw-r-----+ 1 root systemd-journal 128M  6. pro 09.38 user-1000@188c9b557c0a4359ba0ccaa9e6a31e2b-00000000000343d6-00057aea0f8297e1.journal
-rw-r-----+ 1 root systemd-journal 128M 16. led 08.02 user-1000@188c9b557c0a4359ba0ccaa9e6a31e2b-0000000000113844-00057f35dfc07bb9.journal
-rw-r-----+ 1 root systemd-journal 128M 21. led 02.19 user-1000@188c9b557c0a4359ba0ccaa9e6a31e2b-000000000013bc20-00057f8ddab43e39.journal
-rw-r-----+ 1 root systemd-journal  96M 22. led 19.17 user-1000@188c9b557c0a4359ba0ccaa9e6a31e2b-0000000000163adb-00057feda690320d.journal
-rw-r-----+ 1 root systemd-journal 120M 29. čec 14.32 user-1000@85502f274d0842af92d5679bf7d9ef4c-0000000000000017-00056fa7611a2bfe.journal
-rw-r-----+ 1 root systemd-journal 128M 23. srp 18.47 user-1000@85502f274d0842af92d5679bf7d9ef4c-0000000000026071-000572228a93104f.journal
-rw-r-----+ 1 root systemd-journal  64M 29. srp 01.06 user-1000@85502f274d0842af92d5679bf7d9ef4c-0000000000049dfa-0005741d04c76893.journal
-rw-r-----+ 1 root systemd-journal 8,0M 22. lis 19.32 user-1001@4f4b4eb505ee4349b1d025a79ea9d570-000000000006548d-00057486e556966b.journal
-rw-r-----+ 1 root systemd-journal 8,0M 11. led 23.04 user-1001@4f4b4eb505ee4349b1d025a79ea9d570-000000000007073f-00057b45182ada47.journal

Server, dostatek místa ve /var/log/journal, dostatečně dlouhý provoz a příslušné (ne)nastavení v /etc/systemd/journald.conf...

[Aleš Kapica]

Podle mě to není na závadu, protože je pak v případě nouze kam sáhnout aby se uvolnilo místo.

A kromě toho, když něco nefunguje, tak je co prohlížet.

[Peter Golis]

Veľký log nie je samostatnou závadou, ale dôsledkom závady. Zaujímala ma príčina tej závady, ale len okrajovo.

[Aleš Kapica]

Jo ták. No těch příčin bylo mnoho. Je to poměrně nový stroj s AMD a některé chyby (s grafikou) odstranila až nedávná aktualizace jádra.

[Peter Golis]

Ach, áno. Nové železo je peklo. Som rád, že sa už nemusím naháňať za každým MHz. I keď som zažil rovnaký problém keď mi po updatoch prestala ísť prastará grafická karta ATI 9200. Písalo mi to do logov nieč o resetovaní GPU, a zdochlo mi to. Staršie edície na tom žíhali jako namydlený blesk.

Nooo, na mailserveru mám logy dost dlouhé, abych mohl v případě potřeby říct, hoši já jsem váš mail doručil na cílový server a co se s ním dělo potom, to není moje záležitost...

[Andrej]

Můj komentář není rada, nýbrž důležité off-topic varování. (Tohle už tu totiž párkrát bylo.) Btrfs nemá nic takového jako RAID1 na víc než 2 discích!

Tady se to například probíralo.

Pozor na věc; iluze redundance je (pro data) horší než absence redundance. (Protože iluze redundance do značné míry ovlivňuje chování a rozhodování uživatele stran zálohování atd.) Pro RAID1 na víc než 2 discích je nutné mít ZFS.

[lertimir]

Tím chceš říci myslím to, že ať mám kolik chci disku v btrfs RAID1 tak soubor je přávě na dvou z nich, ne na více. S tím souhlasím a proto jsem si to takhle udělal. Více méně když bych to trochu zparafrázoval, tak je to kombinace JBOD a RAID1 (a už vidím, jak tu na mne se někdo oboří, že tak to není :=) )

[Aleš Kapica]

A co tedy dělá raid10?

[lertimir]

Raid10 je stripovaný RAID. Tedy soubor je rozsekán na stripy, ty jsou liché/sudé rozděleny na disky 1 a 2 a celkové stripy 1 jsou zezrcadleny na disk 3 stripy z 2 zezrcadleny na 4. Nebo se stipuje i celé blokové zařízení. Ale to asi těžko, btrfs si metadata řídí jinak. Naproti tomu btrfs RAID 1 je stromová struktura, která provádi duplikace souborů na právě dvě různá fyzická média nežávisle na tom kolik disk je k dispozici právě na dva. Na druhou stranu jak jedna z obrovských výhod btrfs je kontrolní součty mezi fyzickým diskem a pamětí, tak se ubjevuje i jinde, pozorně sleduji vývoj LUKS2 a za chvili budeme mít i autentizované (authenticated modes) šifrování disků. Takže potvrzení spolehlivého přenesení dat z disku do paměti bude už v LUKSu.

[Aleš Kapica]

Kromě toho nemáte pravdu. Btrfs rozhazuje data rovnoměrně. S tím, že nemá dva stejné datové bloky na jednom zařízení.

Jestli to Andrej nemyslel spíš tak, že kdo chce mirror na 3 a více disků, musí to dělat jinak, než s btrfs.

[Aleš Kapica]

Taky mě to napadlo, ovšem nedává mi smysl, proč bych měl na lokálním systému zrcadlit X kopií jednoho a toho samého datového bloku.

[dustin]

Třeba proto, že při výpadku jednoho disku a jeho následné synchronizaci chceš stále udržovat redundanci. Každý disk jednou umře, ale ne každý disk umře současně s jiným. Tudíž k výpadku jednoho disku jednoho dne dojde vždycky. Se dvěma disky v raid1 mám 100% jistotu, že jednoho dne stav bez redundance nastane. Se třemi je taková pravděpodobnost zásadně nižší.

[Aleš Kapica]

U Btrfs v raid1 se začnou dělat nové kopie datového bloku ihned poté, co nějaký disk umře. Pokud je kam. Teda alespoň si to myslím. A protože se replikují pouze datové bloky, je to mnohem rychlejší, než by se zreplikovalo celé zařízení, jako je tomu u MD raidu, nebo u ZFS – pokud je mi známo, tak ZFS redundanci nedělá na úrovni datových bloků, ale zařízení. Ale mohu se mýlit.

Do stavu bez redundace by ses tedy dostal, jen pokud by ti chcípl další disk, na kterém by zrovna byly extenty, které se ještě nestihly zreplikovat. Pro tak extrémní případy, kdy ti disky chcípají náhle jak mouchy po biolitu, však má Btrfs další typy raidu.

[dustin]

Prostě než se překlopí duplikované bloky z mrtvého disku na třetí, jede to bez redundance. To je třeba pro někoho nepřijatelné. Navíc zvýšená zátěž po výpadku disku může vést k výpadku dalšího disku. Jsou prostě situace, kdy 3+ raid1 dává smysl.

ZFS samozřejmě také duplikuje jen obsazené bloky, ne celý disk.

[Aleš Kapica]

ZFS samozřejmě také duplikuje jen obsazené bloky, ne celý disk.

Jestli to je samozřejmé nevím, protože když jsem skládal ZFS, tak vyžadoval pro svoje raid zařízení odpovídající počet disků o stejné kapacitě, takže to v tomto směru bylo stejné jako u MD raidu - můžeš použít různě velké disky, ale kapacitu raidu určuje nejmenší z nich.

Prostě než se překlopí duplikované bloky z mrtvého disku na třetí, jede to bez redundance

V takovém případě se ale nepoužívá raid1, ale raid56

[dustin]

S omezením na nejmenší společnou velikost nemám osobně žádný problém. Ani u md, ani u ZFS. Osobně nevidím v míchání velikostí až tak velkou výhodu - když mi umře největší, může se mi klidně stát, že se na zbylé malé už redundance nevejde a jsem opět bez redundance. Hezká vychytávka, ale pro mě úplně nepodstatná. Naopak si říkám, jak dlouho bude trvat odchytat všechny chyby tak složitého kódu...

ZFS ušetří synchronizaci nepoužitých bloků (což je při mírně obsazených discích samozřejmě zásadní urychlení). MD zase synchronizuje sekvenčně a pokud není pole zatížené, kopíruje max. rychlostí disků.

Raid5/6 nepoužívám, ani na ZFS. Mám rád jednoduché formáty a raději strčím do pole o pár disků víc. Ale někomu to určitě může vyhovovat, to je jasné. Samozřejmě za předpokladu správné funkce a spolehlivosti, to má vždy absolutní přednost.

[lertimir]

u btrfs a stripovaného raidu (tedy raid 10, 5 ,6) bys dopadl stejně.

[Aleš Kapica]

Pochybuji. Ovšem mezi námi, řešit takové věci na jednom lokálním stroji je fakt blbost.

[lertimir]

všiml sis této věty?

If you want to use devices of different sizes, striped RAID levels (RAID-0, RAID-10, RAID-5, RAID-6) may not use all of the available space on the devices. Non-striped equivalents may give you a more effective use of space (single instead of RAID-0, RAID-1 instead of RAID-10).

z btrfs-raid

[Aleš Kapica]

A všiml sis této věty?

řešit takové věci na jednom lokálním stroji je fakt blbost.

[lertimir]

Kopie se budou dělat jen při zápisu a nebo když spustíš balanci. Jen sám od sebe žádné kopie dělat nebude. A podle komentáře/odpovědi tady, tak při btrfs replace start /dev/left /dev/new_device /mnt/foo se btrfs bude snažit přečíst co půjde s padajícího disku.