abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 13:22 | IT novinky

Samsung oznámil, že program Linux on DeX končí. Android 10 už nebude podporován. Linux on DeX umožňuje spouštět linuxový desktop a aplikace z vybraných telefonů od Samsungu připojených pomocí Samsung DeX.

Ladislav Hagara | Komentářů: 13
včera 12:00 | Komunita

Ubuntu slaví 15 let od vydání první verze. Přesně před patnácti lety, 20. října 2004, byla vydána první verze 4.10 s kódovým názvem Warty Warthog.

Ladislav Hagara | Komentářů: 1
19.10. 20:20 | Pozvánky

Ve středu 23. října 2019 se od 16.00 koná akce na téma Oracle Labs - Live for the Code. Představí projekty Oracle Labs, na kterých se pracuje i v České republice: Oracle Labs Data Studio a GraalVM. Místo konání: budova Oracle v Praze–Jinonicích. Vstup po registraci zdarma. Občerstvení zajištěno.

Ladislav Dobiáš | Komentářů: 1
18.10. 09:44 | Upozornění

Byly zveřejněny videozáznamy přednášek z konference LinuxDays 2019, která proběhla 5. a 6. října v Praze. Odkazy na videa společně s prezentacemi naleznete v programu, případně můžete jít rovnou na stránku video. Záznamy pořizovalo Audiovizuální centrum SiliconHill.

Petr Krčmář | Komentářů: 18
17.10. 18:55 | Nová verze

Bylo vydáno OpenBSD 6.6. Opět bez oficiální písně. Z novinek lze zmínit například sysupgrade(8).

Ladislav Hagara | Komentářů: 5
17.10. 08:36 | Nová verze

Vyšla nová verze monitorovacího řešení Centreon 19.10.0. Novinek je spousta (realtime API, podpora JIRA, vylepšený systém notifikací...), ale těmi nejdůležitějšími je pro mnohé uživatele podpora nové verze rrdtool 1.7.x a php 7.2. Systém tak půjde bez problémů provozovat na jiných distribucích než CentOS 7. Kompletní přehled novinek v seznamu změn. Předpřipravená appliance i samotné části jsou k dispozici na oficiálních stránkách.

Max | Komentářů: 0
17.10. 01:00 | Komunita

Dnes vyjde Ubuntu 19.10 s kódovým názvem Eoan Ermine. Přehled novinek v poznámkách k vydání. Ubuntu 20.04 LTS bude Focal Fossa.

Ladislav Hagara | Komentářů: 14
16.10. 22:11 | Zajímavý projekt

Padesátiny Unixu lze oslavit také hrou The Unix Game aneb na unixové roury pomocí Scratche.

Ladislav Hagara | Komentářů: 2
16.10. 21:44 | Komunita

Vývojáři svobodného 3D softwaru Blender oznámili, že nejnovějším firemním sponzorem Blenderu je společnost Adidas. Jedná se o úroveň Corporate Silver, tj. 12 tisíc eur ročně.

Ladislav Hagara | Komentářů: 37
16.10. 18:22 | Komunita

V září proběhla každoroční konference Akademy komunity KDE. Nyní jsou záznamy přednášek dostupné online. Témata se dotýkají aplikací a knihoven KDE, jejich adaptaci pro různá speciální použití (vestavěná zařízení či rozšířená realita) i obecně vývoje a distribuce softwaru.

Fluttershy, yay! | Komentářů: 0
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (20%)
 (4%)
 (11%)
 (39%)
 (24%)
 (2%)
Celkem 441 hlasů
 Komentářů: 23, poslední včera 18:52
Rozcestník

www.AutoDoc.Cz

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

22.1. 21:40 lertimir | skóre: 63 | blog: Par_slov
Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Přečteno: 616×
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 avatar 23.1. 16:18 multi | skóre: 38 | blog: JaNejsemOdsut
Rozbalit Rozbalit vše Za behu
Asi jsi btrfs neodmountoval. Tyto vsechny zmeny se daji a delaji za chodu.

Mozna v bode 2. se disk pripojil...
23.1. 16:54 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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ří.
23.1. 21:48 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Tak jsem si to znovu zkusil a patrně proběhl automout.
24.1. 00:21 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
No. Jo. Takové obskurnosti, jako automount nepoužívám. Ona každá automatika má své meze.
24.1. 00:43 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
:-) já si myslel, že to také nepoužívám.
24.1. 08:35 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.
24.1. 08:45 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Vše je OK. Nic se nestalo.
24.1. 09:09 Peter Golis | skóre: 58 | Bratislava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
1,5 GB logů
To by ma zaujímalo ako sa takéto niečo dá dosiahnuť.
24.1. 09:47 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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í.
24.1. 09:50 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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
24.1. 10:10
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Server, dostatek místa ve /var/log/journal, dostatečně dlouhý provoz a příslušné (ne)nastavení v /etc/systemd/journald.conf...
24.1. 10:16 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Podle mě to není na závadu, protože je pak v případě nouze kam sáhnout aby se uvolnilo místo.
24.1. 10:41
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
A kromě toho, když něco nefunguje, tak je co prohlížet.
24.1. 11:33 Peter Golis | skóre: 58 | Bratislava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Veľký log nie je samostatnou závadou, ale dôsledkom závady. Zaujímala ma príčina tej závady, ale len okrajovo.
24.1. 11:43 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.
24.1. 14:22 Peter Golis | skóre: 58 | Bratislava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.
24.1. 11:45
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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...
24.1. 10:32 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování

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.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
24.1. 11:09 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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í :=) )
24.1. 11:24 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
A co tedy dělá raid10?
24.1. 13:42 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.
24.1. 11:28 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Kromě toho nemáte pravdu. Btrfs rozhazuje data rovnoměrně. S tím, že nemá dva stejné datové bloky na jednom zařízení.
24.1. 11:47
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Jestli to Andrej nemyslel spíš tak, že kdo chce mirror na 3 a více disků, musí to dělat jinak, než s btrfs.
24.1. 13:07 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.
24.1. 13:21 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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žší.
24.1. 13:39 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.

24.1. 13:46 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.
24.1. 14:22 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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
24.1. 14:52 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.
24.1. 14:55 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
u btrfs a stripovaného raidu (tedy raid 10, 5 ,6) bys dopadl stejně.
24.1. 16:40 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
Pochybuji. Ovšem mezi námi, řešit takové věci na jednom lokálním stroji je fakt blbost.
24.1. 18:18 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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

24.1. 19:13 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
A všiml sis této věty?
řešit takové věci na jednom lokálním stroji je fakt blbost.
24.1. 13:57 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Rozšíření btrfs RAIDu - potvrzení/vyvrácení chování
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.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.