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 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
dnes 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
včera 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 7
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (0%)
 (0%)
 (1%)
 (76%)
 (13%)
Celkem 204 hlasů
 Komentářů: 8, poslední dnes 23:02
    Rozcestník
    Štítky: není přiřazen žádný štítek

    Vložit další komentář
    saly avatar 28.12.2015 12:39 saly | skóre: 22 | blog: odi_et_amo
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Ajaj, to není moc pozitivní příspěvek. Na btrfs jedu na laptopu už dýl (SSD, aktuální jádra pod Arch Linuxem) a pohoda. Chce to ale jednou za čas pustit balance i na tom single disku, protože sice volné místo na disku je, ale nejde jinak využít. Teď jsem na btrfs přešel na Cubieboardu (SATA Seagate) a odvážil jsem se ho teď nasadit na nový disk (WD RED 3TB), který je v testování a nahradí mi stávající v NASu (2x disk Seagate Barracuda na ext4). Dám ho tam ovšem až vyjde nová verze Turris OS, kde bude novější jádro než 3.10, protože zas tak odvážný nejsem, vzhledem k tomu, že tam mám i zálohy.
    pavlix avatar 28.12.2015 12:46 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Tak o laptop můžeš celkem lehce přijít o celý, takže se potřebě zálohování nevyhneš.
    saly avatar 28.12.2015 17:07 saly | skóre: 22 | blog: odi_et_amo
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Jo jo, to dělám ... na již zmíněný NAS s btrfs :-D
    28.12.2015 13:58 pavele
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Díval jsi se na smart toho WD RED 3TB? Hlavně na údaj o parkování hlaviček. :-)
    30.12.2015 12:14 kapo | skóre: 14 | blog: runtime
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Tak moje 2 Redy 3TB maji po snad 2 letech cca 50. Zato Seagate ST3000DM001 ma 20500 :).
    Why make things difficult, when it is possible to make them cryptic... - Aksel Peter Jorgensen
    28.12.2015 14:43 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    SSD? A Btrfs jen v single modu? Pravděpodobnost že přijdeš o data je zhruba stejná jako že se aktivní motocyklista dozije ve zdraví a bez nehody padesátky.
    Jendа avatar 28.12.2015 15:14 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Mám 1.7 TB dat na ADATA SSDčkách, která jsem zapsal v létě 2012. Naprasil jsem na to teď check (není to FS, je to přímo na těch devicech) a pustil jsem to, počkej si tak den, než to doběhne.
    28.12.2015 16:10 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Pokud jsi to tam nalil r.2012 a teď se to chystáš přečíst, tak v tom problém není. Taky máme doma starší Asus eee 901 s SSD diskem, který furt žije. Problém SSD disků je v tom, že většinou umírají smrtí náhlou a bez varování. Proto mám nad nimi Btrfs v raid1. Chcípne-li jeden, tak předpokládám že na druhém ta data zůstanou, přinejmenším do doby, než je zreplikuji na SSD které ten mrtvý nahradí.
    Jendа avatar 3.1.2016 10:54 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Jinak dlužím vysvětlení, proč to nedopadlo: tomu stroji zrovna odešla paměť (memtest hlásí červené řádky), musím se tam někdy vypravit a najít a vyndat vadný modul.
    saly avatar 28.12.2015 17:09 saly | skóre: 22 | blog: odi_et_amo
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Mám Samsung SSD PRO, takže doufám, že když na něj dávají záruku 10 let, že si za ním stojí.
    30.12.2015 15:51 Jardík
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Záruku ... na výrobní vady. Řeknou ti, že je to opotřebení a máš smůlu.
    28.12.2015 21:11 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte

    tak to je celkem vysoka, vzhledem k tomu ze vetsina motorkaru ma 45+

    USE="-gnome -kde";turris
    28.12.2015 22:00 Odin1918 | skóre: 4 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    +1
    28.12.2015 21:59 Odin1918 | skóre: 4 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Znate vubec nejake motorkare pane Kapica? Ja jich znam spousty a hodne jich ma jiz padesatku na krku. ;-)
    SSD? A Btrfs jen v single modu? Pravděpodobnost že přijdeš o data
    Co je na kombinaci btrfs + ssd spatneho? Mate nejake konkretni poznatky?
    28.12.2015 23:17 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Znám jich docela dost. Naštěstí ale ty šťastnější, co své nehody víceméně ve zdraví přežili. Kolega, který je o patnáct let mladší má ale statistiku horší.

    Pokud jde o kombinaci, blbě jste to pochopil. SSD je samo o sobě riskantní médium. Což Btrfs je schopno ošetřit, je-li v módu raid1 tedy nad dvěma SSD disky. Je-li v single módu, je to stejný risk, jako u kteréhokoliv jiného FS. Takhle ho používám pouze tam, kde se ukládají pouze zbytna data - zurnalovaci soubory sheepdogu, která se průběžně prepisuji na sice pomalejší, ale trvalejší média.
    Heron avatar 28.12.2015 14:18 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Díky BTRFS csum chybám jsem takhle přišel na vadnou paměť (non ECC).
    28.12.2015 14:30 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Podle mě je v jaderném modulu Btrfs buga. Dokonce se mi ji jednou podařilo odchytit, jenže jsem jí nepřikládal větší význam a nikam neuložil. Bohužel později už jsem to "štěstí" neměl. Stroj při ní totiž vytuhne tak, že ji nelze vydolovat. Do logu se neuloží a na monitor se vypíší už jen hlášky které jsou jejím důsledkem.

    Dochází k ní pokud se přesouvají extenty se kterými se zrovna pracuje, z nebo na fyzické zařízení, a Btrfs je v single modu.

    Když byly extenty Btrfs v raid1, nebo zařízení bylo typu sw raid1 nebo raid6, problém nenastal.

    Stejně tak nenastal pokud systém extenty nepoužíval.
    28.12.2015 14:38 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Ještě k tomu jak se mi ji podařilo odchytit. Byl jsem na tom stroji přihlášen přes ssh a sledoval přes dmesg s parametrem -w jak se přesouvají Btrfs extenty. Pak to najednou vyzvracelo tu chybu a stroj byl ve stavu zombie - tj. žil a nežil. Přestal komunikovat, jen pingal.
    Jendа avatar 28.12.2015 14:38 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Vypadá to tedy, že mi Btrfs právě zachránil zadek, protože mne upozornil na poškozená data, která by běžný filesystém přešel bez jakéhokoliv varování!
    Není nad tím v dmesg taky hláška, že disk vrátil vadný blok, tedy by se to odchytlo i bez btrfs?

    Já mám mismatche na serveru s ECC, asi tak jeden za 100 TB a půl roku, a vůbec nechápu, jak se to může stát. Disky přece používají samoopravné kódy a SATA komunikace po kabelu je taky chráněna CRC. Škoda, že btrfs ani MD nepíšou třeba obsah toho bloku nebo nějak víc informací (byl to bitflip? je celý blok nulový?) a protože je to RAID, tak ho to hned opraví z druhé kopie a nejde to diagnostikovat.
    Cohen avatar 28.12.2015 15:14 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Vypadá to tedy, že mi Btrfs právě zachránil zadek, protože mne upozornil na poškozená data, která by běžný filesystém přešel bez jakéhokoliv varování!
    Není nad tím v dmesg taky hláška, že disk vrátil vadný blok, tedy by se to odchytlo i bez btrfs?

    Právě že není, ve výpisu dmesg není nic, co by naznačovalo, že by se čtením z toho disku bylo cokoliv v nepořádku. (Minimálně tedy nyní, co tam případně bylo při tom prvotním zápisu dat už teď bohužel nezjistím.) Chytá to až Btrfs na úrovni kontroly kontrolního součtu dat.

    Možná ale nebude od věci nechat na tom stroji řádně proběhnout memtest.

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Jendа avatar 10.1.2016 12:16 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    28.12.2015 16:22 elenril
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Nemůžu si pomoct, ale to btrfs mi pořád přijde docela podezřelé. Hlavně tím, jak do sebe cpe hromadu věcí, co IMO mají být v LVM/DM. To je takový problém dodělat ty checksumy do ext4? Gůglení naznačuje, že na něčem takovém se dělá/dělalo, ale moc konkrétních informací jsem nenašel.

    Jinak samozřejmě zálohuju, bup mi poskytuje každodenní zálohy s deduplikací. Za skoro dva roky a zhruba 15 systémů je to na ~150GB (checkout latest verze každého mají dohromady asi polovinu). Jen bych asi měl mít víc fyzicky vzdálených kopií.
    Heron avatar 28.12.2015 16:32 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Hlavně tím, jak do sebe cpe hromadu věcí, co IMO mají být v LVM/DM.
    Některé vlastnosti by při rozdělení na jednotlivé vrstvy nešly dosáhnout (nebo ne tak elegantně). On totiž btrfs není "mechanické" sloučení raid, partition managera, jak se to často chybně vykládá, btrfs na vrstvy nelze rozdělit. Vše vychází z jednoduchého konceptu cow, nad kterým lze poměrně elegantně kouzlit.

    Samozřejmě, projekty LVM / MD tady budou stále dál, nezmizí (už jen proto, že exportují blokové zařízení).
    To je takový problém dodělat ty checksumy do ext4?
    Je. ext4 i xfs mají checksumy metadat.
    29.12.2015 12:58 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    btrfs na vrstvy nelze rozdělit

    Všechno jde, jenom děti se musí nosit... Teda když se chce - a už jsem to psal, tady se nechtělo, protože by to znamenalo míň slávy a víc spolupráce s někým jiným.
    Quando omni flunkus moritati
    Heron avatar 29.12.2015 13:40 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Ale nenapsal jsi, jak by se dalo téhož dosáhnout při rozdělení na vrstvy (s využitím těch stávajících).

    Jendа avatar 29.12.2015 15:23 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Rád bych si poslechl především jak by řešil checksumy (nenapadá mě lepší řešení než jak to má AS/400, kde na disku jsou sektory velké 520B, přičemž 512 je normálně sektor a zbytek je checksum -- ty disky jsou pak skvěle kompatibilní se zbytkem světa) a snapshoty (tam zase znám na úrovni bloků jenom LVM, které je při víc snapshotech s víc změnami nepoužitelně pomalé).
    Heron avatar 29.12.2015 15:33 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Ona by se také docela špatně dělala ta základní funkcionalita.

    Udělat blokové zařízení s podporou cow a snapshoty není až tak těžké. No ale co s tím? Když se nad tím udělá normální fs, tak dobře, můžu mít snapshoty (díky freeze i zcela konzistentní), ale co s nimi? Mít 10tis. připojených fs asi nejde. Nehledě na to, že to nebude umět ani reflinky (natožpak mezi subvolumy). Distribuce volného místa jde, fs bude reportovat (discard) volné bloky, což je ostatně nutné pro každý thin provisionning.

    Dobře, máme lepší lvm a nějaký mountovací manager a umíme snapshoty. To je ale tak vše.

    Jak vyřešit multidevice? Tak, abych mohl přidat disk libovolné velikost a aby se synchronizovaly jen zabrané bloky? Přes bitmapy?

    Jako udělat to tak, aby tam ty vrstvy vidět byly jako nějak lze. Otázkou je, zda to k něčemu bude a otázkou je, zda je vůbec správné v první řadě to na ty vrstvy dělit (z hlediska vývoje úložných systémů to sice logiku mělo, ale otázkou je, zda není na čase to opustit).
    29.12.2015 16:15 Ovocníček
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Nebylo to prostě tak, že byly OSu exponovány low-level sektory z HDD? Protože přímo na plotně v HDD samozřejmě sektor nemá těch 512 B, ale víc a jsou tam kontrolní součty (pomocí těch to taky ví, že při čtení nastala chyba). Jenom jsou používané interně a OS/FS to nevidí.
    Cohen avatar 29.12.2015 18:11 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte

    Jenže data + checksum v jednom bloku neřeší všechno, co dokáže pokrýt Btrfs/ZFS s checksumy ukládanými odděleně od hlídaných dat. Jak zjistíme, že jsme přečetli sice nepoškozená data, ale ze špatného místa disku, tzn. něco jiného, než se mělo přečíst? Co se stane, pokud nějaký zápis na disk omylem a bez povšimnutí neprojde? Pak později přečteme z úložiště blok ze správného místa, checksum dat v něm bude i sedět, ale budou to nějaká jiná data, tj. původní obsah toho bloku, který jen omylem nebyl přepsán novými daty.

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Jendа avatar 29.12.2015 18:58 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Jak zjistíme, že jsme přečetli sice nepoškozená data, ale ze špatného místa disku, tzn. něco jiného, než se mělo přečíst?
    Aha, tak už chápu, proč je tam 4 bajty checksum a 4 bajty číslo sektoru.
    Co se stane, pokud nějaký zápis na disk omylem a bez povšimnutí neprojde?
    Jo, to se nechytí.
    28.12.2015 16:38 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Pozor, problém není v Btrfs, ale v jaderném modulu, který s ním pracuje. Nejsem kernelový guru, abych dokázal určit příčinu, ale současná verze dokáže rozbít za určitých okolností i Btrfs v raid1. Podařilo se mi to souborem virtuálního disku v qed formátu, který byl do virtuálu zpropagován přes file. Vysvětluji si to tak, že Btrfs vně virtuálu ztratilo kontrolu nad obsahem extentu, do kterého se valily další a další data. Problém se týkal obou fyzických zařízení, na které se měl extent replikovat a pomohlo až nové vygenerování chsumů na obou fyzických discích, které se ovšem provádí na zařízeních, které nesmí být připojeny. Což v případě systémového disku znamenalo práci v ramdisku. Proto se snažím mít data u kterých může k takové situaci dojít na odděleném diskovém oddílu.
    28.12.2015 16:34 Ovocníček
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Může to bejt víc věcí, včetně i té chyby na sběrnici. Viděl jsem jeden notebook, co na mass storage discích, jak klíčenkách, tak HDD dělal s poměrně velkou frekvencí potichu korupci dat. Někde asi překlopil nějaký bit, při kopírování velkých souborů se to stávalo tak s frekvencí jeden soubor z pěti. BTW CPU Intel, čipset Intel, údajně vždy stopro stabilní kombinace :)
    28.12.2015 17:27 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    To je lesk a bída současných počítačů.

    1) Spolehlivost netrápí nikoho. Proto se také spolehlivost snižuje.

    2) Poslední procesory jsou vyrobeny tak nízkými nanometry, že chyby v procesoru musejí nutně nastávat už z fyzikálních zákonů. Různé radioaktivní či nabité částice, které se vyskytují úplně všude (přirozené rádiové pozadí), mají zde zvýšený vliv. I z tohoto důvodu mám nejdůležitější počítače s 45 nm procesory.

    3) MB a RAM paměti se pro běžné desktopy vyrábějí bez ECC – to by se lidé divili, kdyby ECC bylo!!! To by bylo smutku!!!

    Kromě toho operační systém neumí na ECC chybu v RAM nijak vhodně zareagovat, pouze to celé shodí.

    4) Architektura operačních systémů je také snaha „poručit větru dešti“ s tím, že se ignorují fyzikální zákony. Monolitický operační systém, který má kernel obsahující řádově 10 miliónů řádků zdrojového kódu, a který musí pro dobrý chod být bez chyby – fyzikální zákony naprosto vylučují to, že by zde chyba nebyla, přesněji, že by v kernelu nebyly obrovské mraky chyb. (To platí pro Linux i Windows.)

    Původní unix princip byl: „mít malé a jednoduché jádro (do pár desítek tisíc řádků zdrojového kódu), které je dokonale odladěno a považováno za bezchybné“. Na tom to bylo postaveno, a to je v souladu s tím, co fyzikální zákony ještě reálně umožňují.

    5) Lidi na úložných médiích zajímá jediné: kapacita a rychlost. Protože HDD a SSD si konkurují, oba druhy zkoušejí velmi experimentální metody uložení dat, jako jsou popsány v článku, zejména pro zvýšení kapacity.

    Jakékoli novinky na HDD jsou nespolehlivé. SSD je nespolehlivé už z principu, a rok od roku je to horší. SSD je snad jediná technologie, která se s časem zhoršuje, klesá její životnost, spolehlivost, rychlost, zvyšuje se spotřeba (která už brzy předstihne spotřebu HDD a občas se tak už stalo).

    Vlastně je smutné, že HDD s mechanickými částmi spolehlivostí skvěle konkuruje SSD bez jakýchkoli pohyblivých částí. Už to samo o sobě říká, že SSD je něco shnilého a nespolehlivého.

    Nastal prostě trend shitových úložišť, kde jde především o kapacitu a levnou cenu. Spolehlivost nikdo neřeší. Dnešní SSD neudrží data, pokud rok nezapnete počítač či zařízení, kde ho máte. (Zdůrazňují dnešní, dnes koupená. Dříve to bylo lepší.)

    6) Linux obsahuje miliardu filesystémů. Namísto toho, aby se vzaly jako základní jeden, možná dva, v nejhorší tři – ty se pořádně odladily, a vše ostatní bylo bráno jako nevýznamné. Upřímně, zde je strategie Microsoftu rozumnější: nerozmnožuje zbytečně filesystémy, a pořádně kartáčuje a vyvíjí NTFS.

    Je jasné, že v těch driver filesystémů bude také mraky chyb.

    7) Zálohu jsem vyřešil tak, že zálohuji komprimované balíčky ZIP/RAR/7Z, které samy o sobě obsahují kontrolní součty. Bez ohledu na filesystém tak mám kontrolu, zda je soubor v pořádku – a nemusím používat experimentální a potenciálně chybové filesystémy jako btrfs jen proto, že mají kontrolní součet.

    Opět jsem zvolil antilinuxové řešení, neukládám tar + něco, ale obvykle zip či 7z, kde komprimovaný balík ví o souborech, které obsahuje, přímo, a také o nich má přímé informace a pracuje separátně s každým z nich zvlášť.

    Kromě toho mám výhodu v komprimaci, mnohem lepší, než by dokázal jakýkoli zálohovací systém sám o sobě. Navíc větší soubory efektivněji využívají místa na disku. A pokud si navíc na zálohovacím médiu vytvoříte větší clustery, protože malé soubory neukládáte, zjendoduší se i struktura disku/filesystému a je to o krapítek spolehlivější a rychlejší.

    8) Problém je, že spolehlivá záložní média nejsou. Trh je nepožaduje, navíc lidé mají na počítači většinu věcí, o které mohou bez problémů přijít. Trh požaduje vysoké kapacity a rychlé čtení.

    Spolehlivost a údržnost dat na médiích nepožaduje nikdo.
    28.12.2015 18:47 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Pane, že jste svým způsobem blázen už nějaký čas víme, ale že to jde až daleko, to jsem netušil. Uvědomujete si, že nabourany archiv je větší průser než nabouraný FS, který byl navržen tak, aby ho bylo možné opravit?
    28.12.2015 19:08 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Dobrá, budu s vámi diskutovat stejným způsobem, jako vy se mnou.

    Že jste, pane Kapico, svým způsobem idiot, to už všichni vědí, ale uvědomujete si, že nabouraný filesystém nemusí být opravitelný stejně dobře jako archív?

    Nebourat neopravitelně jde všechno. V tom případě je dobré vědět, zda jsou data v pořádku (kontrolní součet), nebo ne.
    28.12.2015 19:35 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Od toho je souborový systém, aby zachoval data v pořádku. Smysl komprimovaných archivů je poněkud jinde. Pokud použijete FS, který vám nezajistí konzistenci dát, tak zálohu z poškozeného archivu neobnovíte, ani kdyby jste se rozkrájel. Leda byste měl pro každý takový archív uloženy někde bokem opravné ecc kódy, o čemž silně pochybuji že máte. Ale vaše data, váš problém.
    Jendа avatar 28.12.2015 23:27 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Leda byste měl pro každý takový archív uloženy někde bokem opravné ecc kódy, o čemž silně pochybuji že máte.
    par2 c archv.7z
    Jendа avatar 28.12.2015 23:25 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Pane, že jste svým způsobem blázen už nějaký čas víme, ale že to jde až daleko, to jsem netušil.
    1-5 má pravdu

    V 6) bych nesouhlasil, podle mě se většina práce koncentruje právě na ext a btrfs, tak jako kdyby jiné FS neexistovaly.

    V 7) bych doporučil nemít jen kontrolní součty, ale rovnou samoopravné kódy. Například pomocí programu par2.

    8) Kup si víc nespolehlivých.

    Osobně mě štve, že SLC karty a SSDčka nestojí méně než 3x víc než TLC (jak by se řeklo logicky), ale 10x víc.
    29.12.2015 00:08 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Reagoval jsem především na bod 7. Už v několika jiných diskuzích p. Ponkrác ukázal že technologicky poněkud ustrnul - proto jsem si také neodpustil onu invektivu. Ovšem řešit problematiku fyzických blokovych zařízení a souborových systémů použitím komprimovaných archivů bez toho, že by k nim souběžně generoval opravné kódy, tak tím mne fakt dostal.
    Heron avatar 29.12.2015 08:36 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    V 6) bych nesouhlasil, podle mě se většina práce koncentruje právě na ext a btrfs, tak jako kdyby jiné FS neexistovaly.

    Docela se máklo na xfs a RedHat to má jako default (RHEL 7).

    29.12.2015 19:23 peter
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Lepsie archivacne programy su urcene aj na zalohu dat a vedia pridat recovery info, co je v podstate parita, alebo treba pouzit par2.
    28.12.2015 20:50 Kvakor
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    To je lesk a bída současných počítačů. 4) Architektura operačních systémů je také snaha „poručit větru dešti“ s tím, že se ignorují fyzikální zákony. Monolitický operační systém, který má kernel obsahující řádově 10 miliónů řádků zdrojového kódu, a který musí pro dobrý chod být bez chyby – fyzikální zákony naprosto vylučují to, že by zde chyba nebyla, přesněji, že by v kernelu nebyly obrovské mraky chyb. (To platí pro Linux i Windows.)
    Ha, kdyby jen fyzikální, to by ještě šlo řešit redundancí a vzájemnou kontrolou. Problém je v tom, že u netriviálních programů teoreticky vůbec nejde zjistit, jestli chyby obsahují nebo ne, viz problém zastavení. Sice je možné pokusit se o formální verifikaci, kdy se koreknost programu posuzuje pomocofí matematických metod, jenže bohužel je to zatraceně náročné (z toho důvodu se to dělá jen u věcí, kde se to opravdu vyplatí), zadruhé i samotná matematika má své limity, viz Gödelovy věty o neúplnosti (osobně si myslím, že existuje hluboké spojení těchto vět a výše zmíněného problému zastavení, možná dokonce i problému P versus NP).
    Heron avatar 28.12.2015 21:47 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    :-)
    Poslední procesory jsou vyrobeny tak nízkými nanometry
    A proč zrovna 45nm? Proč ne stovky mikrometrů jako pro družice? Odkud se vzalo zrovna 45?
    MB a RAM paměti se pro běžné desktopy vyrábějí bez ECC – to by se lidé divili, kdyby ECC bylo!!! To by bylo smutku!!!

    Zkušenosti s něco přes 1TB RAM a 8 let běhu (jistě, velikost paměti postupně rostla) hovoří něco jiného. Opravitelné chyby ECC jsou velmi vzácné (na prstech jedné ruky do roka). Neopravitelnou jsem neviděl ani jednu. To už je častější, že odejde celý modul.

    Když jsem doma viděl detekovanou ECC v L3 CPU, tak to byl svátek. Zatím jen jednou (a to se v té paměti motá víc dat vyšší rychlostí, než v systémové ram).
    Architektura operačních systémů je také snaha „poručit větru dešti“ s tím, že se ignorují fyzikální zákony.
    Jasně. Jinak chtěl bych vidět někoho, kdo reálně využívá celé jádro. To, že je to monolit nic neznamená, jelikož nikdo nemá zavedené všechny moduly a ani omylem nepoužívá vše, co jádro v celku nabízí. Jednotlivé běhy budou využívat jen zlomek z celkového kódu (a to navíc ještě tu nejpoužívanější a nejotestovanější část).
    Lidi na úložných médiích zajímá jediné
    To se možná týká disků pro spotřebu, ale ne pro DC.
    ty se pořádně odladily
    Co to konkrétně znamená pořádně odladit fs? Všechny používané fs jsou po implementační stránce odladěné.

    Další a zásadnější problém je s požadavkem na jeden fs. Žádný FS nemůže z principu vyhovovat všem situacím, všem pracovním zátěžím. Některé požadavky jdou přímo proti sobě. Jde to vidět i na NTFS, na nějaký průměrný případ průměrného desktopu je připraven dobře. To jo. Ale všude jinde je to katastrofa, stejně jako by to byla katastrofa pro kterýkoliv jiný fs mimo jeho sweet point. Toto je důvod, proč mít víc fs. Aby bylo z čeho vybírat pro danou konkrétní situaci.
    Zálohu jsem vyřešil tak, že zálohuji komprimované balíčky ZIP/RAR/7Z, které samy o sobě obsahují kontrolní součty.
    Gratulujeme. Pořád používají CRC32 na celý soubor? Úžasné. V BTRFS je to na každý 4kiB blok. Zatím CRC32, místo je až na 256b a prostor pro jiné funkce. Bokem mám navíc i sha512 sumy celých souborů (to jsem původně začal používat už dřív pro detekci silent data corruption na disku, za hromadu let ani jeden problém).
    Problém je, že spolehlivá záložní média nejsou.
    Jsou. Otázkou je, nakolik se vyplatí do nich investovat (= jak drahá data potřebujeme zálohovat).
    Jendа avatar 28.12.2015 23:31 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    A proč zrovna 45nm? Proč ne stovky mikrometrů jako pro družice? Odkud se vzalo zrovna 45?
    Protože stovky mikrometrů mělo naposledy originální Pentium a 22 let staré procesory už se blbě shání a provozují?
    Jde to vidět i na NTFS
    Už se vlastně Windows naučily dělat ekvivalent MD RAIDu, LVM a snapshotů?
    28.12.2015 23:50 Ovocníček
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    "Stovky" jsou přesně co? Pentia III s taktem 550 MHz ještě byla 250nm (shánět jádro Katmai), také první Ahtlony K7 s podobnými takty byly 250nm. Na 180 nm byly Athlony XP s taktem IIRC okolo 1,6 - 1,7 GHz, a Pentia 4 (ale ta moc dobrá nebyla, IIRC). na 130 nm se dají mít kromě slušných Pentií 4 Northwood s takty po 3,něco GHz také Athlony 64 a Opterony.

    Jinak je to samozřejmě blbost. Nebo minimálně pomýlené obsedantní lpění na nevýznamném detailu, když drtivá většina nestabilit a nehod se stane z jiným příčin.

    --------------------------------------

    Před pár lety Windows dostaly něco nazvané Storage Spaces a ReFS, ale jsem línej si k tomu zjišŤovat víc, většina infa, kterou k tomu dává Google, je stará 3 roky (z doby vydání W8).
    Jendа avatar 29.12.2015 00:11 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    29.12.2015 01:04 sigma
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Už se vlastně Windows naučily dělat ekvivalent MD RAIDu, LVM a snapshotů?
    Minimálně u snapshotů je situace snad i lepší než na linuxu. VSS (Volume Shadow Copy) je k dispozici od Win XP / Server 2003. Jsou to snapshoty na úrovni FS se všemi výhodami s tím spojenými. Tj. něco, co v linuxu "máme" až s Btrfs. LVM snaphoty se tomu fakt neblíží.

    Snapshoty mají i GUI integraci (předchozí verze souborů), což navíc nativně funguje i přes síť (k tomu lze tedy donutit i Sambu nad ZFS nebo Btrfs).

    Kromě toho ACL systém na NTFS je rozhodně mocnější než POSIX ACLs, u kterých už jsem sám na limity několikrát narazil. Situace se srovnatelnými nfsv4 ACL je v linuxu hodně smutná...

    MD RAIDu a LVM odpovídají tzv. dynamické disky (Dynamic Disks and Volumes, https://technet.microsoft.com/en-us/library/cc737048(v=ws.10).aspx) - k dispozici od Win 2000. Dříve tam byla nějaká omezení při provozu v clusteru nad SAN, a bylo třeba používat místo toho např. Veritas Volume Manager, aktuální stav už moc neznám.
    Max avatar 29.12.2015 07:54 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Tak tak, souhlas. Jinak také mi z části přišla snapshotovací fce VSS ve windows lepší, jak v linuxu. Jde o to, že ve win s tím každá app počítá. Když se tedy provede VSS, tak všechny služby flushnou data (Exchange, MSSQL apod.) a docílí se tak i plně konzistentní zálohy. V linuxu si to člověk musí řešit "ručně", tzn. před vytvořením snapshotu je třeba říci všem běžícím app, aby flushly data na disk.
    Jinak jak už bylo řečeno, Dynamic Disks je něco jako LVM a MD, ale né tak propracovaný. Umí to základy, nic pokročilejšího, ale zato je to plně klikací.
    VSS je také dobré pro file share, kde se dá naklikat vytváření VSS třeba každou hodinu, čímž se tvoří historie souboru/dat a lze tak data obnovit po velmi krátkých časových intervalech.
    Zdar Max
    PS: Nedávno mi jeden SBS2008 padal vždy v celou, ale náhodnou hodinu. Problém byl nejspíše v tom, že se dělal často VSS, pole mělo větší latence, na onom oddílu byl pagefile (swap file). Po přesunutí pagefile na oddíl, kde je VSS vypnuté server běží bez výpadku.
    Měl jsem sen ... :(
    4.1.2016 16:39 Chulda | skóre: 19
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    No, to VSS zas tak mocné není. Nezjišťoval jsem design/implementaci VSS, ale co se stane, když to aplikace do nějaké doby nestihne?

    Pod vmware je občas tuna chyb ve windows, které jsou obzvláště roztomilé, viz KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007696 nebo http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2006849

    Nejraději mám tu chybovou hlášku s ID 157 "Disk x has been surprise removed.", ale je to jen warning :-)

    Heron avatar 29.12.2015 08:43 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Protože stovky mikrometrů mělo naposledy originální Pentium a 22 let staré procesory už se blbě shání a provozují?
    Neplést si mikro a nano ;-). Plácl jsem schválně stovky mikrometrů a upřímně ani nevím, jestli někdy byl cpu takhle velkou planární metodou vyroben (asi ne).

    Jinak, on má někdo skutečný problém s velikostí dnešních tranzistorů v cpu? Jak se to projevuje?

    29.12.2015 16:02 Ovocníček
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Protože stovky mikrometrů mělo naposledy originální Pentium a 22 let staré procesory už se blbě shání a provozují?
    Neplést si mikro a nano ;-). Plácl jsem schválně stovky mikrometrů a upřímně ani nevím, jestli někdy byl cpu takhle velkou planární metodou vyroben (asi ne).

    A jo, to jsem si nevšim. Stovky mikrometrů asi fakt ne. Si mě splet tím Pentiem, prototože to IIRC bylo tak na 800 - 500 nm (hmm, wikipedia říká že 0.8 µm až 0.25 µm u nějakých pozdních mobilních verzí, mainstream skončil na 350nm, kde začalo Pentium II).

    U Intelu 8080 byla "minimum feature size" 6 µm, u 4004 10 µm. Takže asi tak. Ono taky co je stovka mikrometrů, že jo? To by se toho na wafer moc nevešlo.

    Jinak, on má někdo skutečný problém s velikostí dnešních tranzistorů v cpu? Jak se to projevuje?
    Myslím že nemá a nijak :) Řeší to samozřejmě výrobci čipů, protože musí víc bojovat s úniky proudu a je to těžší vyrobit, ale nám plebsu to může být jedno, i když možná někdo má iluze vlastní důležitosti a říká si, že on přece potřebuje něco lepšího.
    Heron avatar 29.12.2015 16:18 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Si mě splet tím Pentiem
    Pentium plácl Jenda, já nic, já muzikant :-D
    Myslím že nemá a nijak :) Řeší to samozřejmě výrobci čipů, protože musí víc bojovat s úniky proudu a je to těžší vyrobit, ale nám plebsu to může být jedno, i když možná někdo má iluze vlastní důležitosti a říká si, že on přece potřebuje něco lepšího.
    Asi tak.
    29.12.2015 19:49 Ovocníček
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Sorry! Holt problém udržet pozornost, prostě, no...
    Heron avatar 29.12.2015 21:03 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Moc ovoce, to chce maso :-D
    28.12.2015 22:13 Odin1918 | skóre: 4 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Různé radioaktivní či nabité částice, které se vyskytují úplně všude
    Kristalova koule patrne emituje mnozstvi osklivych castic. Doporucuji poridit dostatecne silnou olovenou krabicku, do ktere budete kouli pred zapnutim pocitace vkladat. Timto resenim se dostanete klidne na 14 nm. ;-)
    Tomáš Bžatek avatar 28.12.2015 20:06 Tomáš Bžatek | skóre: 29 | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte

    Pekny clanek a zjisteni.

    FYI, WD heliove disky nevyrabi, vsechna slava jde na vrub nedavno plne spolknute HGST. A stejne tak Seagate pred casem pohltil diskovou divizi Samsungu, takze honit se za znackou nema v dnesni dobe moc smysl. Jen je potreba si davat bacha :-)

    Koupim litajiciho tucnaka
    Cohen avatar 4.1.2016 17:44 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte

    Jsem neustále ve skluzu ve čtení RSS, takže jsem k tomu došel proklikem až dnes ráno v šalině – tak HGST už má i heliem plněné 10 TB, ale ty už navíc používají taky SMR. :-/

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Cohen avatar 17.1.2016 17:01 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Cohen avatar 3.2.2016 00:17 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    29.12.2015 13:51 Sten
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Ze zkušenosti: btrfs balance nad hodně používaným RAIDem 10 občas deadlockuje. Nepodařilo se mi to ale debugovat, ale stávalo se mi to, jen pokud jsem použil víc než 4 disky.
    oryctolagus avatar 29.12.2015 16:01 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Stručný závěr: Btrfs ještě chce nějaký vývoj, ale už teď vážně zvažte jeho použití
    Už teď? Po 6 letech vývoje? :-D No, sice se tomu směju, ale ono je to reálně spíš smutné, btrfs by mělo být vlajkovou lodí, ale moc to tak zatím nevypadá.

    Cool fíčury jako checksums, snapshoty, subvolumes atd. sice vypadají lákavě, ale pokud FS nemá robustnost, tak nemá nic. V tomhle ohledu imho není nad XFS, spolehlivější a odolnější FS neznám.

    Kdybych jó chtěl tyhle pokročilý featury, tak bych spíš koukl po ZFS.

    Mimochodem, nedávno se mi na androidím telefonu nějak záhadně pokazil F2FS, takže tomu už taky nevěřim...
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    Heron avatar 29.12.2015 16:23 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Už teď? Po 6 letech vývoje? :-D No, sice se tomu směju, ale ono je to reálně spíš smutné, btrfs by mělo být vlajkovou lodí, ale moc to tak zatím nevypadá.
    Já používám btrfs pátým rokem. Nevím, proč by mělo být k smíchu, že někdo něco doporučuje po 6 letech vývoje, přičemž:
    imho není nad XFS
    FS z roku 1993, na linux portovaný 2001. Tedy 22 od narození, 14 let od portace. Pořád ještě je těch 6 let k smíchu?
    oryctolagus avatar 29.12.2015 19:24 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Ale jo, chápu, že to trvá dlouho, spíš mě ale není úplně sympatický ten přístup - přijde mi, že featury mají přednost před robustností... Možná to je jen dojem.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    Cohen avatar 29.12.2015 20:02 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Cool fíčury jako checksums, snapshoty, subvolumes atd. sice vypadají lákavě, ale pokud FS nemá robustnost, tak nemá nic. V tomhle ohledu imho není nad XFS, spolehlivější a odolnější FS neznám.

    Pokud chce člověk pod Linuxem stabilní otestovaný filesystém, má Ext*/XFS. Jenže to nyní přestává stačit, takže bez těch cool features by Btrfs neměl smysl (nabízel by jen větší nestabilitu bez jakékoliv přidané hodnoty oproti uvedeným filesystémům). Smysl nového filesystému je právě v tom, že bude umět nové kousky. Že odladění a prověření časem a reálným provozem trvá dlouho, to je realita současného vývoje software, která u souborových systémů platí dvojnásob (i když by se mi také líbilo, pokud by stabilizace a vývoj Btrfs šel rychleji).

    Kdybych jó chtěl tyhle pokročilý featury, tak bych spíš koukl po ZFS.

    Jenže Btrfs má pod Linuxem docela výraznou výhodu ve standardní integraci – je to GPL kód v jádře. ZFS z licenčních důvodů takto pěkně fungovat nemůže, navíc do Linuxu „nezapadá“ – pokud vím, tak se ZFS není dobře integrovatelný s VFS, ZFS svazek se pod Linuxem nedá připojit klasicky přes mount, ale musí se používat jedna ze ZFS obslužných utilit (pokud si toto myslím špatně, prosím o opravu, nejsem si tím 100% jistý). A nakonec Btrfs má oproti ZFS i některé návrhové výhody (bohužel se mi nedaří dohledat, kde jsem četl takový pěkný seznam funkcí, které Btrfs má a ZFS ne a popis toho, jak ZFS designově vychází ze správy dat v paměti, což vede k některým nevýhodám, např. problémů při odebírání zařízení, které se jednou začalo používat apod. :-().

    To ale samozřejmě nic nemění na tom, že ZFS je v reálném světě výrazně odladěnější a otestovanější, takže bych se ZFS pod Linuxem asi neměl větší problém ani pro opravdové produkční nasazení (i když...), kdežto u Btrfs bych se toho zatím stále bál, jak jsem nakonec zdůvodnil v původním zápisku.

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Heron avatar 29.12.2015 20:57 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    ZFS není dobře integrovatelný s VFS

    Tady má BTRFS taky škraloup:

    Pokud přečtete velký soubor, tak při druhém čtení už je celý v iocache (pokud se tam vleze) a je to maximálně rychlé.

    Jenže, pokud uděláte snapshot dané subvolume a čtete stejný soubor na tom snapshotu, tak se opět čte z disku, i když to jsou stejné bloky. Takže tentýž soubor skončí v iocache podruhé.

    Opakovné čtení souboru na subvolume test ("zdrojové"):

    dd if=test/file of=/dev/null bs=1M
    4474+1 records in
    4474+1 records out
    4692282082 bytes (4.7 GB) copied, 0.737969 s, 6.4 GB/s
    

    Po snapshotu (subvolume test na subvolume test1) :

    btrfs sub snap test test1
    Create a snapshot of 'test' in './test1'

    První čtení z této test1 subvolume ("cílové"):

    dd if=test1/file of=/dev/null bs=1M
    4474+1 records in
    4474+1 records out
    4692282082 bytes (4.7 GB) copied, 10.1259 s, 463 MB/s

    Další čtení:

    dd if=test1/file of=/dev/null bs=1M
    4474+1 records in
    4474+1 records out
    4692282082 bytes (4.7 GB) copied, 0.73834 s, 6.4 GB/s

    Toto není problém při běžném použití, ale pokud se čte napříč snapshoty, které vznikly z jedné subvolume (a tedy obsahují většinou shodná data a odkazy na stejné bloky), tak se zbytečně čtou tytéž bloky stále dokola.

    Cohen avatar 22.2.2016 10:26 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    A nakonec Btrfs má oproti ZFS i některé návrhové výhody (bohužel se mi nedaří dohledat, kde jsem četl takový pěkný seznam funkcí, které Btrfs má a ZFS ne a popis toho, jak ZFS designově vychází ze správy dat v paměti, což vede k některým nevýhodám, např. problémů při odebírání zařízení, které se jednou začalo používat apod. :-().

    Dneska jsem na to náhodou asi znovu narazil. Myslím, že jsem měl na mysli toto: A short history of btrfs [LWN.net]

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Jendа avatar 29.12.2015 20:06 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Kdybych jó chtěl tyhle pokročilý featury, tak bych spíš koukl po ZFS.
    U ZFS mě štvalo, že nejdou do zpoolu dávat různě velká zařízení, ani vlastně nejde dynamicky zmenšovat (nevím jestli jde vůbec zvětšovat).
    Cohen avatar 4.1.2016 17:46 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    BTW, dnes jsem se pročetl k tomu, že nadcházející LTS Ubuntu 16.04 asi bude umět instalovat kompletní systém na ZFS. Jsem docela zvědavý, jak to bude integrované.
    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    31.12.2015 19:03 kolcon | skóre: 15 | blog: kolcon
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    ...xfs, pokud vam teda obcas nevadi soubor plny nul (osobni zkusenost po vypadku napajeni)
    31.12.2015 19:30 tom62 | skóre: 14 | blog: tom62 | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Mám bohužel podobnou zkušenost (nevím, zda tam byly nuly, ale původní obsah rozhodně ne). Měl jsem jeden počítač, u kterého tvrdé restarty byly z nejrůznějších důvodů poměrně časté, zkoušel jsem XFS, ReiserFS a Ext4 a jediný posledně jmenovaný se mi nikdy nerozsypal (ale může jít o náhodu).
    31.12.2015 22:47 Filip Jirsák
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    To byla vlastnost XFS. Před X lety. Dneska už se tak XFS nechová.
    H0ax avatar 2.1.2016 09:38 H0ax | skóre: 36 | blog: Odnikud_nikam
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Moje zkušenost cca 2r zpět - 2T svazek raid1, xfs, po restartu nenajel, fsck fs opravil tak, že mi sesypal všechny soubory na hromadu, místo názvů udělal čísla a samozřejmě odstranil koncovky. To je mi pak jedno, že ta data mám, když vím prd, co jsou zač a kde původně byla. Tou robustností si u xfs teda jist nejsem. Co se mi hodně líbí je dir quota, to nic jinýho nemá.
    LinuxWay | blog |  LiCo
    2.1.2016 14:12 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Co se mi hodně líbí je dir quota, to nic jinýho nemá.
    Ale má - Btrfs.
    H0ax avatar 2.1.2016 19:24 H0ax | skóre: 36 | blog: Odnikud_nikam
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    V btrfs holt ještě nemám tu důvěru nicméně ty quoty testnu, díky.
    LinuxWay | blog |  LiCo
    Bedňa avatar 30.12.2015 05:30 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Keď už chcem vážne dáta mať niekde uložené, stále aj po rokoch víťazí ReiserFS. Za roky jediný FS kde sa mi nič nestratilo ani pri zlyhaní HW.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    31.12.2015 22:19 BLEK.
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Já žádná data nemám, protože trpím poruchou osobnosti (byla mi diagnostikována psycholožkou). Myslím, že pan Reiser také trpí nějakou poruchou, protože zabil svou ženu (možná neuměla plavat a jemu to vadilo), teď je ve vězení a vývoj ReiserFS pokulhává. Reiser4 stále není v kernel mainline.
    Mám poruchu osobnosti.
    31.12.2015 23:33 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Reiser4 je v kopru a navíc dávno překonaný.
    Bedňa avatar 1.1.2016 03:15 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Heh, heh, heh a čím?
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    8.1.2016 19:07 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Jen pro informaci všech přítomných. Btrfs má v současném stable řadě jádra 4.3 bugy, které řeší patche, co jsou zařazeny až do jádra 4.4, takže i když ještě není stabilizované ( zatím je venu 4.4-rc8 ), tak se asi - pokud Btrfs používáte a můžete si to dovolit - aktualizace vyplatí.

    Ty chyby jsou totiž dost nepříjemné - především v tom, nemusí jít dodatečně opravit. Při běžném provozu na ně nejspíš nenarazíte, ale pokud používáte virtualizaci a velké virtuální disky tak ano.
    Cohen avatar 8.1.2016 19:12 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte

    A nějak konkretizovat by to šlo? Tj. kterých z těch mnoha bugů se máme nyní konkrétně bát? :-)

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    8.1.2016 22:31 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte
    Podle kolegy Pavla za chybou na kterou jsem narazil já, vězí kód, který opravuje tento patch:

    commit bb1591b4ea1a1485ebc79be4e4748e94f96c670b

    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.