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í
×
dnes 05:00 | Nová verze

Byla vydána verze 5.0.0 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata (Wikipedie). Přehled novinek v oficiálním oznámení a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Zajímavý projekt

Byly zveřejněny schémata, firmware a instrukce pro sestavení trackballu Ploopy. Ten používá Arduino, senzor PMW3360 a 1,75palcovou kouli. Zdrojové soubory jsou šířeny pod open-hardware licencí CERN a GNU GPLv3. Tvar je inspirovaný klasickým trackballem Microsoft Trackball Explorer, jehož výroba byla ukončena kolem roku 2005 bez náhrady; projekt Ploopy se k tomu ale z právních důvodů nehlásí. Již vyrobené díly je možno objednat za 200 kanadských dolarů. Další podrobnosti v příspěvcích uživatele crop_octagon na Redditu.

Fluttershy, yay! | Komentářů: 9
včera 20:22 | Nová verze

Vyšlo desktopové prostředí KDE Plasma 5.17. Novinkou je např. „noční režim“ (pro X11, nejen Wayland), skrytí upozornění při prezentacích (když je připojena obrazovka se stejným obrazem), lepší podpora HiDPI, optimalizace využití zdrojů a mnoho drobných zlepšení a oprav.

Fluttershy, yay! | Komentářů: 2
včera 12:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 169. brněnský sraz, který proběhne v pátek 18. října od 19:00 v restauraci Racek (Jungmanova 5). Před srazem proběhne v 18:00 komentovaná prohlídka nových prostor hackerspacu base48 (přístup je z Mojmírova náměstí).

Ladislav Hagara | Komentářů: 8
včera 05:55 | Bezpečnostní upozornění

V příkazu sudo byla nalezena a ve verzi 1.8.28 byla již opravena bezpečnostní chyba CVE-2019-14287. V souboru /etc/sudoers lze nastavit, aby daný uživatel mohl konkrétní příkaz spouštět s právy libovolného uživatele (ALL) nebo libovolného uživatele kromě uživatele root (ALL, !root). Spustí-li tento uživatel daný příkaz se sudo s volbou -u#-1 nebo -u#4294967295, tj. pod uživatelem -1 nebo 4294967295, nebude vyžadována autentizace a příkaz se spustí pod právy roota.

Ladislav Hagara | Komentářů: 1
včera 01:33 | Nová verze

Po více než roce a čtvrt od vydání verze 3.7.0 byla vydána nová verze 3.8.0 programovacího jazyka Python. Přehled novinek v aktualizované dokumentaci. Podrobný přehled změn v Changelogu.

Ladislav Hagara | Komentářů: 15
14.10. 16:11 | IT novinky

Ke zhlédnutí na Invidious a YouTube je videozáznam rozborky a sborky mobilního telefonu Librem 5.

Ladislav Hagara | Komentářů: 47
14.10. 13:33 | Komunita

Richard Stallman, zakladatel hnutí svobodného softwaru, se dnes v e-mailové konferenci guix-devel vyjádřil, že svobodný software je apolitický, resp. jedinou přípustnou politikou je politika svobodného softwaru. Reagoval na některé návrhy, že by se do svobodného softwaru měl zabudovat feminismus nebo jiný -ismus. Říká, že témata jako komunismus nebo sexuální orientace jsou „off-topic“. Je v pořádku mít politické názory, ale lidé

… více »
xkucf03 | Komentářů: 104
14.10. 05:55 | Nová verze

Po téměř dvou letech vývoje od vydání verze 2.0 byla vydána verze 2.1.0 svobodného softwaru ScummVM (Wikipedie) umožňujícího bezproblémový běh mnoha klasických adventur na zařízeních, pro které nebyly nikdy určeny. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 3
13.10. 10:55 | IT novinky

Josef Průša představil novou 3D tiskárnu Original Prusa MINI. Její cena je 9 990 Kč a tisknout lze na ní objekty do velikosti 18 × 18 × 18 cm.

Ladislav Hagara | Komentářů: 41
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (19%)
 (4%)
 (11%)
 (39%)
 (24%)
 (2%)
Celkem 401 hlasů
 Komentářů: 22, poslední 23.9. 08:36
Rozcestník

Úklid btrfs

16.4.2018 23:59 | Přečteno: 2233× | Linuxové drobty | poslední úprava: 17.4.2018 00:00

Opět drobný zápis pro podpoření paměti. Tentokrát k btrfs systému. V btrfs se velmi vyplatí mít čas od času scrub

Vyvoláme
btrfs scrub start /mount-point-of-btrfs
o běhu a o konci běhu se přesvědčíme
btrfs scrub status /mount-point-of-btrfs
pokud status zobrazi nenulový počet nenapravitelných chyb např.
        total bytes scrubbed: 2.21TiB with 2 errors
        error details: csum=2
        corrected errors: 0, uncorrectable errors: 2, unverified errors: 0
tak je také zajímavé (a potřebné) zjistit v jakých souborech je problém. A pokud jako v mém příkladu jsou na FS 2 chyby error details: csum=2 tak z dmesg zjistíme kde jsou.
dmesg | grep "checksum error at" | tail -2 | cut -d\  -f24- | sed 's/.$//'
případně zapipujeme do souboru > chyby.txt

Co s tím závísí na tom, jak jsou ta data nutné, jsou-li v záloze nebo je-li potřeba obnovy. V každém případě btrfs chybná data nedá. Tedy sektor s chybou součtu skončí s chybou čtení a není dodán. V krajním případě lze použít ddrescue, které nakopiruje soubor bez poškozeného sektoru. To má smysl jen v případě nějakých streamů, kdy data za chybou mají smysl a lze je rozumně interpretovat.        

Hodnocení: 100 %

        špatnédobré        

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

Komentáře

Vložit další komentář

17.4.2018 08:33 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
pokud status zobrazi nenulový počet nenapravitelných chyb…
Tak to znamená, že jsem někde něco nedomyslel a měl bych okamžitě uvažovat o nápravě.
19.4.2018 20:43 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Nevím čím to vzniko. A napravovat nic asi nebudu. Je to 3TB rotační disk, domácí desktop. Na něm je LUKS v a něm je BTRFS. BTRFS zahlásilo chybu. Nicméně pravidelné long testy smartu přímo na disku nikdy nic nezahlásily. A LUKS funguje v pořádku. Na disku byly 2 btrfs chyby ve dvou souborech. Nejsou to kritická data, jsou to vesměs soubory (filmy) z netu, ale chci mít přehled že jsou v pořádku a tak projíždím jak long testy tak scrub. Finálně jsem soubory zkopíroval pomocí ddrescue. Kopírování nahlásilo jeden chybny 4096B velký sektor. Další data na jiných discích nic nehlásily. Chtěl jsem to uklidit a potřeboval jsem najít v jakém jsou souboru. (v podstatě by mi nevadilo ani celý soubor smáznout) Ext4 by mi chybu nenašlo.
19.4.2018 22:47 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Vzniklo to tím, že máš pod tím Btfs jen jeden fyzický disk. Takže když ti na něm odejde nějaký sektor, tak jak známo, kde nic není, ani smrt nebere.

Už se to tady nesčetněkrát omílalo, že Btrfs v single módu jedině nad nějakým raidem. Není to sice všemocné, ale lepší než drátem do oka. Optimální minimum je Btrfs v raid1 nad třemi disky.

Zrovna teď nastala modelová situace. Btrfs v raid1 nad 3x 10TB disky. Jeden z nich začal jít do kopru. Protože je ale pole z 90% zaplněné, nezbývá než počkat na nový disk. Až dorazí, nahradí se jím ten vadný a pak se to prohodí. Nicméně až na poslední operaci, kterou je vyjmutí vadného disku z počítače, lze všechno z toho realizovat za běhu, bez toho aniž by bylo nutné přerušit práci. To s jiným typem FS nedáš.
19.4.2018 23:20 Petr
Rozbalit Rozbalit vše Re: Úklid btrfs
Proc by to neslo s jinym fs? Se zfs menim disky dle potreby bez restartu.
20.4.2018 08:38 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Možná je to dnes už jinak, ale svého času, pokud vím, vyžadovalo ZFS aby byly disky pokud možno stejné nebo větší. Do Btrfs raid1 lze zapojit disky různé.

V případě zmíněné modelové situace – kdybych měl k dispozici potřebnou kapacitu alespoň v 1x1TB, 2x2TB a 1x5TB, a v bedně dost místa a SATA portů tak bych na nic nečekal. Jenže ten stroj je stará desktopová šunka, co má jen 4 SATA porty. A dotyčný odmítl upgrade na lepší stroj. Takže si holt musí počkat. Nicméně to půjde. Původně tam chtěl mít opět Ext4. S takovou by už měl ty data dávno v kopru, tak jako už se mu to stalo jednou předtím.
20.4.2018 16:30 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Pro mne btrfs v single modu nad jedním diskem je pořad lepší než ext4 ve stejné situaci. O chybě se dozvím.
xkucf03 avatar 21.4.2018 15:40 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Úklid btrfs
Už se to tady nesčetněkrát omílalo, že Btrfs v single módu jedině nad nějakým raidem. Není to sice všemocné, ale lepší než drátem do oka. Optimální minimum je Btrfs v raid1 nad třemi disky.

A teď ještě poraď, jak do toho zakomponovat šifrování. Pokud bude pod RAIDem, tak se vše bude muset šifrovat dvakrát, což zpomalí zápisy. A pokud bude nad, tak Btrfs nemůže těžit z toho, že má dvě kopie dat a pokud je někde chyba, tak je velká pravděpodobnost, že ta druhá kopie je dobrá.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
22.4.2018 16:43 Want
Rozbalit Rozbalit vše Re: Úklid btrfs
Logicky bych očekával šifrování jako transparentní vrstvu nad FS. Tudíž nechápu proč by mělo probíhat 2x. Souborový systém ukládá data, a je mu úplně putna jak vypadají. Max. ho zajímá jak dobře půjdou zkomprimovat.
xkucf03 avatar 22.4.2018 16:58 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Úklid btrfs

Tzn. použil bys EncFS? Nebo něco jiného nad Btrfs?

Já zatím vždy používal LUKS (a až nad ním LVM a pak FS), protože pak mám jistotu, že je šifrované všechno včetně metadat, swapu nebo dočasných adresářů, takže by nikde nemělo nic unikat.

Asi nejlepší by bylo transparentní šifrování v rámci FS…

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
22.4.2018 18:08 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Logicky bych očekával šifrování jako transparentní vrstvu nad FS.
Takže NAD FS. V principu se používají asi 3 hlavní typy šifrování. Na úrovni blokového zařízení. -> šifrují se sektory. LUKS. Na úrovni souborů -> šifrují se soubory. EncFS. Na úrovni kontejneru. -> Ve FS je velký soubor, který obsahuje jiný zašifrovaný FS -> Truecrypt/Veracrypt. Při použití šifrování NAD FS múže utočník vidět vlastnosti jednotlivých souborů (velikost, čas zápisu atd) i když obsah a jméno bude zašifrované. Protože k zašifrovnému FS se dostane vždy a protože tam už to je roseparová na soubory, tak je vidí. Běžně se používá LUKS. Typicky tak, že je RAID v něm je LUKS a v něm je FS. Tím se data vytvořené ve FS zpracují v LUKSu a v Raidu se počítá parita/duplicita již ze zašifrovaných bloků. Tím se šifruje blok jednou. Protože btrfs má RAID v sobě, tak použití LUKSu pod ním musí se musí provést zašifrování na každém blokovém zařízení zvlášť. Jediná rozumná cesta do budoucna je mít uvnitř btrfs také šifrování.
xkucf03 avatar 22.4.2018 19:31 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Úklid btrfs
Jediná rozumná cesta do budoucna je mít uvnitř btrfs také šifrování.

+1

Neříkám, že EncFS je nepoužitelný, ale IMHO je to vhodné tak na uživatelská data, dokumenty. Jinak použiji raději ten LUKS.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
22.4.2018 22:48 Want
Rozbalit Rozbalit vše Re: Úklid btrfs
Nepřipadáte si krapet paranoidní? Já se spíš setkávám s tím, že lidi chtějí svoje data vydolovat než definitivně pohřbít.

Ano, dovedu si představit situace, kde má šifrování dat smysl, ale rozhodně to není úroveň lokálního fs.
22.4.2018 23:20 ehm
Rozbalit Rozbalit vše Re: Úklid btrfs
Člověk, který tvrdí, že šifrování disku nedává smysl, jen nemyslel na všechny případy. Daň za šifrování (zprovoznění, nižší výkon, obtížnější mountování disku z jiného systému / livecd) je natolik malá, že se to u běžných počítačů vyplatí snad vždy. Výjimku naopak budou představovat případy, kdy se to nevyplatí.
23.4.2018 09:04 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Ano, dovedu si představit situace, kde má šifrování dat smysl, ale rozhodně to není úroveň lokálního fs.
23.4.2018 10:36 ehm
Rozbalit Rozbalit vše Re: Úklid btrfs
V tom případě ten komentář asi nechápu. Co myslíš tím lokálním FS?
23.4.2018 15:39 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Lokální FS je např. zrovna Btrfs.
23.4.2018 21:42 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Asi jsi chtěl komentovat Wanta a ne ehm. ne?
23.4.2018 22:07 Want
Rozbalit Rozbalit vše Re: Úklid btrfs
Proč bych komentoval sám sebe? ;-) Want je nick když nejsem přihlášený a píšu z mobilu.

Pokud jde o šifrování. Pokud bych chtěl něco šifrovat v rámci lokálního stroje, tak bych využil loop na šifrovaný soubor. V takovém případě ovšem nemá smysl používat Btrfs a sáhnul bych spíš po ext3.

V případě distribuovaného úložiště mi naopak přijde další šifrování jako zbytečný overkill.
23.4.2018 23:36 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Pokud mám v lokálním desktopu více disků, na kterých mám raid, tak z fyzickou bezpečností jsem na tom skoro stejně jako s jedním diskem. Když mi ho někdo fyzicky vezme tak šifrování ochrání data před jeho čtením. Takže tam data šifruji. Samozřejmě data v servrovně s bezpečnostím režimem na přístup se šifrují málo kdy. Možná jen když je majitel chce uchránit i před přístupem z třípísmených agentůr. Ala protonmail.
24.4.2018 08:47 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Pokud mám v lokálním desktopu více disků, na kterých mám raid, tak z fyzickou bezpečností jsem na tom skoro stejně jako s jedním diskem.
Já bych tedy řekl, že o řád lépe. Jeden fyzický disk představuje riziko, jaké bch už dnes podstupovat nechtěl. Proto mám ostatně i v notebooku Btrfs v raid1.

Pokud jde o data. Nepovažuji žádná svoje data za tak citlivá, aby se mi vůbec vyplatilo řešit. Resp. citlivá data třetích stran podle mě nemají na osobním notebooku vůbec co dělat.

Když už bych do podobné situace byl postaven, že bych je přeci jen musel někde udržovat, tak bych to vyřešil — jak jsem naznačil výše – velkým souborem (u kterého bych v případě Btrfs nastavil atribut 'nocow'), který bych připojil přes loop. A na ten bych aplikoval kryptování na úrovni blokového zařízení.

A pak ať se na tom disku hrabe kdo chce. I když z mého pohledu – dávat k reklamaci zařízení s datovým diskem… No. Někdo to tak asi dělá. Záleží na tom, jaký má problém. Já jsem dosud reklamoval pouze chcíplé disky. U strojů to nebylo nikdy zapotřebí. Pokud něco chcíplo, tak to bylo po několika letech provozu a definitivně.
24.4.2018 14:01 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Ok. Pokud vám Vaše data nestojí za to, přistup k nim řešit, jsme každý na jiné planetě. Mě za to stojí. A pokud to někomu připadá paranoidní budu paranoidní rád.
24.4.2018 14:13 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
A přesně o tom je svoboda. Každý ať si nakládá se svými daty jak chce.
23.4.2018 21:55 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Jak souvisí "definitivně pohřbít" s šifrováním? Ke svým zašifrovaným datům mám klíče, nebo kvalitní hesla, a přístup mám zajištěn. Šifrování disků má smysl primárně v situaci, kdy nemohu zabezpečit ochranu fyzického přístupu k systému (diskům) a naopak mohu zabezpečit to, že v případě, kdy systém (disk) nemám plně pod kontrolou, tak je vypnutý. Což je např. šifrování lokálního FS v notebooku nebo stolním počítači. V krizovém případě, že notebook (desktop) někdo ukradne (at již cíleně nebo náhodou) k datům se nemůže dostat.
xkucf03 avatar 23.4.2018 22:02 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Šifrování a reklamace

A další dobrý důvod k šifrování jsou reklamace – nikdy nevíš, kdo si bude chtít na vráceném „rozbitém“ disku zkoušet, co vše lze obnovit, a kam tvoje data pak budou putovat. Nikdo ti nezaručí, že reklamovaný disk jen zkontrolují a pak bezpečně zničí.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
20.4.2018 08:54 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: Úklid btrfs
Kdysi jsem někde četl, že fsck od btrfs umí díky checksumům poškozené sektory bruteforce dopočítat a tím takovéhle 4kB bloky zachránit. Existuje tedy na to nějaký nástroj a je to vůbec možné v reálném času bruteforce dopočítat?
20.4.2018 11:36 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Nevím. Každopádně, pokud by něco takového bylo součástí kódu, tak je to v něm rovnou implementované. Situace kdy je chyba neopravitelná znamená, že už nepomůže ani svěcená voda.

Pro někoho je asi nezvyklé, že z takového sektoru nelze data jednoduše vydolovat. Je to dáno filozofií přístupu k datům. Z lidského pohledu jsou poškozená data lepší než žádná. Ale jen proto, že jejich následnou analýzu zajistí lidský mozek. Pokud bychom však taková data použili k dalšímu zpracování, tak by mohlo dojít devalvaci i dat původně nepoškozených.
20.4.2018 20:24 Petr
Rozbalit Rozbalit vše Re: Úklid btrfs
To by jsi hodne dlouho bruteforcoval aby jsi dostal ze 4kB spravny checksum...
21.4.2018 11:08 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
Checksum není kryptografická hash funkce. BTRFS používá Castagnoli implementaci CRC32 (podobně jako ext4 nebo CEPH) označovanou CRC32C a má HW akceleraci v SSE4.2.
21.4.2018 22:25 Petr
Rozbalit Rozbalit vše Re: Úklid btrfs
To urcite, ale jak chces rychle vygenerovat z niceho neco co ma treba 0x22620404 checksum? Mozna to nevidim, ale porad je to dost prace, nebo ne? Pocitat crc z dat je rychle.
22.4.2018 15:54 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
No primárně CRC není jednosměrná funkce. Pokud by ses jenom trošičku začetl do toho článku na wiki na který jsem dal odkaz, tak víš jednak, že CRC je lineární funkce tedy crc součtu je součet crc sčítanců a jednak jak se počítá, tedy že je to v podstatě zbytek po dělení nějakým polynomem, takže trivíálně uděláš opačný postup, kdy se zbytku a polynomu vypočteš bity, které jsou rozdílné.
22.4.2018 19:11 Kkt1
Rozbalit Rozbalit vše Re: Úklid btrfs
Super,dekuji za objasneni.
20.4.2018 23:25 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Úklid btrfs
No to je blbost. Není problém "dopočítat" jakou změnou by se kontrolní součet dostal na správnou hodnotu, problém je v tom, že takovýchto možných změn, které by to provedly, je možné hodně, a je nerozhodnutelné, která je správně. Obecně opravné a detekční kódy pracují tak, že přidáním bitů navíc jsou opravitelné popř. detekovatelné některé druhy chyb. (třeba jeden bit opraví dva bity detekuje na 8 bytů) V závislosti na povaze chyb jsou některé kódy odolnější třeba proti "burst módu" tedy více chyb v blízkém okolí, jiné jsou odolnější proti statisticky náhodném rozdělení chyb. Vždy se musí počítat i s tím, že chyby mohou nastai i v oblasti kontrolních bitů. Nicméně vždy, když chyby přesáhnou možnosti kódu, je to konec. řešeních pak je hodně.
17.4.2018 09:42 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Úklid btrfs
pokud status zobrazi nenulový počet nenapravitelných chyb např.
Ono i když btrfs reportuje, že se mu podařilo chybu opravit, asi bych měl i tak zkontrolovat stav disku, typ chyby, důležitost dat na tom disku a zamyslet se nad tím, zda nechci ten disk vyměnit. Např. pokud by v případě popsaném v blogu byly ty 2 chyby jako na potvoru v btrfs metadatech, které mají ve výchozím nastavení 2 násobnou duplikaci, tak by btrfs vypsal, že nalezl 2 chyby, ale že se mu je podařilo opravit (z té druhé kopie). Na druhou stranu, taková chyba nemusí být vždy způsobená přímo diskem.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
17.4.2018 13:34 petr
Rozbalit Rozbalit vše Re: Úklid btrfs
Dle tohodle blogu mam pocit, ze btrfs sice chybu detekuje, ale neumi ji opravit. Je to tak, nebo tomu jenom nerozumim? Myslel jsem, ze je jaksi self healing jako treba zfs.
17.4.2018 13:58 Adolf Kernel
Rozbalit Rozbalit vše Re: Úklid btrfs
ZFS (na BSD a Solaris) je ina liga...
17.4.2018 15:03 petr
Rozbalit Rozbalit vše Re: Úklid btrfs
ano, pouzivam na freebsd, proto se ptam, jestli mimo ku*veni dat ten alfafs je opravdu neumi opravit....
17.4.2018 20:37 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Nemel o tom čemu nerozumíš.
17.4.2018 14:31 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Úklid btrfs
Btrfs při čtení každého bloku[1] kontroluje, zda jeho obsah sedí na checksum, který má z dřívějška uložený. Pokud tohle sedí, data jsou předaná dál a čtení z filesystému proběhne. Pokud ale checksum nesedí, podívá se zda není někde uložená další kopie tohoto bloku, a pokud ano, zda u něj sedí checksum. Pokud existuje a jeho checksum sedí, btrfs ten první blok přepíše obsahem toho druhého, a vrátí správná data, tj. čtení normálně proběhne a chyba se opraví. Pokud ale žádný takový další blok neexistuje nebo pokud ten checksum u kopie taky nesedí, není data jak opravit a vrátí se chyba čtení.

[1] Myslí se blok z pohledu filesystému, tj. min. jednotka, s kterou filesystém pracuje.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
17.4.2018 15:08 petr
Rozbalit Rozbalit vše Re: Úklid btrfs
takze to funguje podobne jako u zfs. Jeste jeden dotaz pokud se tomu rozumis - je mozne nastavit u btrfs treba 2 kopie v ramci jednoho poolu? Nebo to musis zrcadlit aby jsi mel vice kopii treba kritickych dat? U zfs pouzivam u kritickych dat vice kopii.
17.4.2018 16:14 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Úklid btrfs
Jo, je možné použít duplikaci dat i u jediného disku (tj. bez použití zrcadlení), zapíná se to přes mkfs.btrfs -d dup .... A jak píšu víše, takto se ve výchozím nastavení ukládají akorát metadata. Viz Btrfs Glossary:
DUP: A form of "RAID" which stores two copies of each piece of data on the same device. This is similar to RAID-1, and protects against block-level errors on the device, but does not provide any guarantees if the device fails. DUP is btrfs default RAID level for metadata on a single, non-rotational device. Regular data can also be assigned the DUP profile.
Ale sám jsem to nikdy nepoužíval, protože btrfs mám jen na ssd disku a tam je to s velkou pravděpodobností stejně k ničemu (smysl by to mělo jen s rotačním diskem), viz: DUP PROFILES ON A SINGLE DEVICE
The mkfs utility will let the user create a filesystem with profiles that write the logical blocks to 2 physical locations. Whether there are really 2 physical copies highly depends on the underlying device type.

For example, a SSD drive can remap the blocks internally to a single copy thus deduplicating them. This negates the purpose of increased redundancy and just wastes filesystem space without the expected level of redundancy.

The wear levelling techniques can also lead to reduced redundancy, even if the device does not do any deduplication. The controllers may put data written in a short timespan into the same physical storage unit (cell, block etc). In case this unit dies, both copies are lost. BTRFS does not add any artificial delay between metadata writes.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
17.4.2018 23:55 petr
Rozbalit Rozbalit vše Re: Úklid btrfs
Dekuji, zajimave. Zfs funguje asi podobne s tim, ze tech kopii mohu definovat vicero v ramci jednoho poolu.
19.4.2018 22:48 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
Dekuji, zajimave. Zfs funguje asi podobne s tim, ze tech kopii mohu definovat vicero v ramci jednoho poolu.
Ale ne v rámci jednoho blokového zařízení, jak by si mohl někdo myslet.
19.4.2018 23:25 Petr
Rozbalit Rozbalit vše Re: Úklid btrfs
Jasne. Alesi, jak to funguje treba kdyz mas 3 disky v raid1 a zapnuty ten dup profile? Mas na kazdem disku 2x data, nebo ty data mas 2x v ramci toho raid1?
20.4.2018 00:47 Sten
Rozbalit Rozbalit vše Re: Úklid btrfs
V Btrfs je RAID stejné nastavení jako single nebo dup (a můžete mít jiný RAID pro data a metadata na stejném poli), takže buď máte raid1 nebo dup. Pokud použijete dup s více disky, jsou všechny bloky v tom poli 2×, ale na rozdíl od raid1 není zaručené, že jsou na různých discích.
20.4.2018 08:40 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
DUP profile se používá pouze pro metadata. I když by možná na data šel použít taky. Jeho smysl je ovšem pouze v tom, že v případě vadného sektoru neodejde do kopru celý FS.

Je to cca to samé, jako u GPT, které je uloženo na disku také do několika oblastí.
Nicky726 avatar 29.4.2018 09:50 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Úklid btrfs
Srub (a balance) se vyplatí mít obalený systemd unitou s timery. Pak se to pouští pravidelně a člověk jen občas koukne na logy.

Jinak to vypadá, že v 4.16 jsou nějaké opravy zrychlující scrub nad mnoha pododdíly/snapshoty:
[root@makoto ~]# journalctl -u scrub-btrfs.service 
-- Logs begin at Sun 2018-04-15 19:00:34 CEST, end at Sun 2018-04-29 09:43:13 CEST. --
dub 22 01:00:00 makoto systemd[1]: Starting Scrub BTRFS filesystems...
dub 22 01:00:04 makoto scrub-btrfs.sh[6746]: Running scrub on /mnt/maintenance/makoto_data_btrfs/
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]: scrub device /dev/mapper/makoto_data3_luks (id 3) done
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         scrub started at Sun Apr 22 01:00:04 2018 and finished after 06:19:13
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]: scrub device /dev/mapper/makoto_data4_luks (id 4) done
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         scrub started at Sun Apr 22 01:00:04 2018 and finished after 06:32:22
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]: Running scrub on /mnt/maintenance/makoto_ssd_btrfs/
dub 22 07:32:41 makoto scrub-btrfs.sh[6746]: scrub device /dev/vda (id 1) done
dub 22 07:32:41 makoto scrub-btrfs.sh[6746]:         scrub started at Sun Apr 22 07:32:26 2018 and finished after 00:00:15
dub 22 07:32:41 makoto scrub-btrfs.sh[6746]:         total bytes scrubbed: 4.64GiB with 0 errors
dub 22 07:32:42 makoto systemd[1]: Started Scrub BTRFS filesystems.
-- Reboot --
dub 29 01:00:00 makoto systemd[1]: Starting Scrub BTRFS filesystems...
dub 29 01:00:04 makoto scrub-btrfs.sh[18795]: Running scrub on /mnt/maintenance/makoto_data_btrfs/
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]: scrub device /dev/mapper/makoto_data3_luks (id 3) done
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         scrub started at Sun Apr 29 01:00:04 2018 and finished after 02:23:39
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]: scrub device /dev/mapper/makoto_data4_luks (id 4) done
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         scrub started at Sun Apr 29 01:00:04 2018 and finished after 02:27:53
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]: Running scrub on /mnt/maintenance/makoto_ssd_btrfs/
dub 29 03:28:12 makoto scrub-btrfs.sh[18795]: scrub device /dev/vda (id 1) done
dub 29 03:28:12 makoto scrub-btrfs.sh[18795]:         scrub started at Sun Apr 29 03:27:57 2018 and finished after 00:00:15
dub 29 03:28:12 makoto scrub-btrfs.sh[18795]:         total bytes scrubbed: 5.62GiB with 0 errors
dub 29 03:28:12 makoto systemd[1]: Started Scrub BTRFS filesystems.
[root@makoto ~]# uname -a
Linux makoto 4.16.4-1-ARCH #1 SMP PREEMPT Tue Apr 24 13:21:29 UTC 2018 x86_64 GNU/Linux
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
xkucf03 avatar 29.4.2018 13:52 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Úklid btrfs

BTW: neumí to cesty k chybným souborům ukládat v nějakém strojově čitelném formátu? V man btrfs-scrub jsem to nenašel. Tzn. je potřeba prohledávat log a tahat to z něj?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Nicky726 avatar 29.4.2018 14:46 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Úklid btrfs
AFAIK je potřeba tahat z logu. Někde jsem na to, tuším, viděl i nějaký skriptík.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
29.4.2018 19:03 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Úklid btrfs
A kam jinam než do logu bys chtěl ty zprávy o chybách ukládat? Ale asi by to chtělo mít líp zdokumentovaný formát té zprávy.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
xkucf03 avatar 29.4.2018 19:43 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Úklid btrfs

Mohl by být dostupný třeba přes /proc jako seznam oddělený nulovým bajtem nebo jako symbolické odkazy na dané soubory. Případně by parametrem příkazu btrfs scrub mohl být soubor, kam se má zapisovat nebo by to šlo prostě na standardní výstup (při použití parametru -B). Případně by si BTRFS mohl do svých metadat ukládat seznam poškozených souborů a pak by sis je příkazem btrfs scrub něco vypsal.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
29.4.2018 20:32 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Úklid btrfs
Mohl by být dostupný třeba přes /proc
V /proc asi ne, protože tam informace z konkrétního filesystému nepatří. Ale i kdybychom uvažovali, že to narveme do sysfs informací, co jsou v /sys/fs/btrfs, tak to není zcela dobrý nápad vzhledem k potenciální velikosti a provázanosti takových dat.
Případně by parametrem příkazu btrfs scrub mohl být soubor, kam se má zapisovat nebo by to šlo prostě na standardní výstup (při použití parametru -B).
To by byl trochu problém, protože to běží v kernelu.
Případně by si BTRFS mohl do svých metadat ukládat seznam poškozených souborů a pak by sis je příkazem btrfs scrub něco vypsal.
Tohle už je trochu lepší nápad, ale pořád je to něco co by mohlo udělat víc škody než užitku. Ideálně bych chtěl, aby scrub na filesystém nešahal mimo případy opravy dat.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
30.4.2018 08:45 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Úklid btrfs
A co si takhle doplnit filtr do logovacího démona a tyhle zprávy odkládat do samostatného logu? To je podle mě standardní postup.

Obsah adresáře /proc se (pokud vím) při restartu zahazuje, takže v případě kdy by chyba vedla ke zhrouzení jádra byste akorát žili v blažené nevědomosti, že vám hnije blokové zařízení pod FS, protože by chyba nebyla ani tam, ani ve standardním logu.

Ale popravdě řečeno. Proč takové opičárny? Když hledám chybu, hledám ji především v syslogu. A stačí mi na to grep a less.
xkucf03 avatar 3.6.2018 15:39 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Úklid btrfs

Koukám, že už nějaké práce na standardizaci/sjednocení probíhají, dokonce pro různé FS :-)

Btrfs podporuje „drhnutí“ za chodu a ext4 se má časem přidat. Wonga zajímalo, zda by nešlo vytvořit společné rozhraní v uživatelském prostoru. Ted Ts'o řekl, že by se hodilo ujasnit si, co je cílem a jaké jsou požadavky na takový nástroj. Zeptal se, jestli jediná úloha v cronu má drhnout všechny souborové systémy, nebo by ext4 a XFS měly mít samostatné záznamy v crontabu. Cílem by samozřejmě mělo být usnadnit správcům systémů život.

Chris Mason vznesl téma kontrol CRC, který souborové systém provádějí dnes. Když tyto kontroly selhají, každý souborový systém zaznamená svá vlastní oznámení do dmesg. Není v tom žádná konzistence. Wong doporučil, aby Btrfs uživatelskému prostoru vracel chybový stav „souborový systém poškozen“ (filesystem corrupt), jako to dělají ext4 a XFS, ale Mason namítl, že chyby CRC se najdou i jindy než při „drhnutí“ souborového systému.

Zdroj: Jaderné noviny – 17. 5. 2018: „Drhnutí“ a oprava souborového systému XFS za chodu

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes

Založit nové vláknoNahoru

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