Portál AbcLinuxu, 6. května 2025 06:21
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 systemMohu zkušenější poprosit o radu, co s tím? Je tam Centos 7.3. Díky, KR
Řešení dotazu:
31.8.2017 08:04
Max | skóre: 72
| blog: Max_Devaine
31.8.2017 08:13
vandrovnik | skóre: 21
31.8.2017 08:26
vandrovnik | skóre: 21
31.8.2017 08:38
Max | skóre: 72
| blog: Max_Devaine
no vono je dobry se na pripadnou havarii pripravit predem... Nez neco nasadim v produkci tak otestuju DR.
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).
3.9.2017 21:01
vandrovnik | skóre: 21
musíte souborový systém odmountovat a přimountovat v režimu degradedTak neargumentuj jak Miloš Zeman, ok? Parametr remount dělá totiž přesně tohle, akorát že v jednom příkazu.
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.
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.
4.9.2017 09:24
vandrovnik | skóre: 21
4.9.2017 09:38
vandrovnik | skóre: 21
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
4.9.2017 10:17
vandrovnik | skóre: 21
Umřel disk, po restartu jsem btrfs pro archiv provozoval v degraded režimuProč?
provozoval v degraded režimu, read-write vs. protože v degraded režimu naběhne jen read-onlyProtiř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.
4.9.2017 10:27
vandrovnik | skóre: 21
Protože nám přišlo lepší po dobu reklamace mít archiv na jednom disku než ho nemít vůbec.Umřel disk, po restartu jsem btrfs pro archiv provozoval v degraded režimuProč?
provozoval v degraded režimu, read-write vs. protože v degraded režimu naběhne jen read-onlyPoprvé 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.)
4.9.2017 10:49
vandrovnik | skóre: 21
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
4.9.2017 10:54
vandrovnik | skóre: 21
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.
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í.
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.
4.9.2017 10:21
vandrovnik | skóre: 21
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.
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í.
4.9.2017 13:23
vandrovnik | skóre: 21
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.
4.9.2017 14:11
Jendа | skóre: 78
| blog: Jenda
| JO70FB
4.9.2017 14:56
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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.
4.9.2017 15:10
Jendа | skóre: 78
| blog: Jenda
| JO70FB
4.9.2017 20:58
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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.
4.9.2017 22:11
Jendа | skóre: 78
| blog: Jenda
| JO70FB
vypadl disk, pole se automaticky přehodí do degradovaného módu, a já jdu koupit nový; mezitím všechno normálně fungujeJak jste přišel na to, že by to mělo být jinak?
4.9.2017 20:44
Jendа | skóre: 78
| blog: Jenda
| JO70FB
4.9.2017 22:11
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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.).
-o degraded.
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.
4.9.2017 22:14
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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.
pole se automaticky přehodí do degradovaného režimuAle 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.
1.9.2017 07:30
Max | skóre: 72
| blog: Max_Devaine
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ý.
. 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.
4.9.2017 23:58
Max | skóre: 72
| blog: Max_Devaine
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í.
5.9.2017 10:54
Max | skóre: 72
| blog: Max_Devaine
5.9.2017 09:49
vandrovnik | skóre: 21
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.
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
6.9.2017 09:21
Max | skóre: 72
| blog: Max_Devaine
4.9.2017 22:16
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Takze kdyz budu mit 1000 serveru, budu muset mit o 1000 disku navic kvuli brtfsNe. 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 ;).
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 nesplnujeNa 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.
aby to po vypadku disku jelo dalCož 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 resenimTo 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.
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.
4.9.2017 23:45
Max | skóre: 72
| blog: Max_Devaine
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.
6.9.2017 15:41
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
7.9.2017 10:50
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
1.9.2017 00:53
k3dAR | skóre: 63
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?
3.9.2017 21:13
vandrovnik | skóre: 21
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 doneV /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
4.9.2017 09:26
vandrovnik | skóre: 21
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).
4.9.2017 09:50
vandrovnik | skóre: 21
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ě?
4.9.2017 20:56
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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 #
#!/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 | tails 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ů?????
musel bych tudíž v nějakém okamžiku udělat btrfs balanceProč?
tak ho neudělám, protože btrfs raid1 už na to nemá místo při zaplnění asi na 50% své kapacityCož 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.
#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.
OK. Tak tedy:Připadá vám, že tohle je vytažení disku ze šuplíku?#btrfs balance btrfsmnt
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
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?
btrfs balance start -dusage=10 btrfs balance start -dusage=30 btrfs balance start -musage=10 btrfs balance start -musage=30mi 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.
RH má tým specialistů na XFS a nepodařilo se mu sehnat vývojáře na btrfs, kteří by byli ochotni pro RH pracovatToto 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.
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.
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.
6.9.2017 13:55
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
) 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š.
6.9.2017 14:59
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
mkfs.btrfs -d raid1 -m raid1 /dev/sd[b-f]
for i in `seq 1 100` ; do dd if=/dev/urandom of=$i bs=1M count=10 ; done
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
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.device delete za normálního stavu) a automaticky to dosyncuje data.
Test na deb testing, kernel 4.12, btrfs tools 4.12-1.
6.9.2017 15:21
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
6.9.2017 16:42
vandrovnik | skóre: 21
7.9.2017 22:09
vandrovnik | skóre: 21
13.11.2017 13:25
Max | skóre: 72
| blog: Max_Devaine
BTRFS : Allow a degraded read-write mount if all the raid profile constraints are met [zdroj]Zdar Max
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?
# mkfs.btrfs -f -m raid1 -d raid1 /dev/sdb /dev/sdc # wipefs -a /dev/sdb # mount /dev/sdc /mnt/btrfs -o degraded
13.11.2017 14:03
Max | skóre: 72
| blog: Max_Devaine
mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdcPak by jsi teoreticky mohl připojovat v degradovaném režimu oba disky.
17.11.2017 11:24
vandrovnik | skóre: 21
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.