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:55 | Humor

Banksy před několika dny šokoval umělecký svět svým obrazem, jenž se přímo v aukční síni po svém prodeji za více než 30 milionů korun sám částečně skartoval. Z obrazu Dívka s balónem vznikl obraz Láska v koši. Command Line Magic ukazuje, jak na podobného Banksyho z příkazového řádku.

Ladislav Hagara | Komentářů: 0
včera 16:55 | Komunita

Handshake, decentralizovaná certifikační autorita a peer-to-peer DNS aneb DNS v blockchainu, postupně rozděluje mezi svobodné a open source projekty celkově 10,2 milionu dolarů. V srpnu získalo 300 000 dolarů GNOME a 100 000 dolarů GIMP. Dnes oznámila nezisková organizace KDE e.V. zastupující komunitu kolem KDE v právních a finančních záležitostech, že od Handshake získala 300 000 dolarů, z čehož 100 000 dolarů je alokováno pro multiplatformní balík svobodných kancelářských a grafických aplikací Calligra.

Ladislav Hagara | Komentářů: 3
12.10. 15:44 | Nová verze

Po třech letech od vydání verze 5.0 byla vydána nová major verze 6.0 v Javě napsané aplikace pro komplexní návrh rozmístění nábytku a dalšího vybavení v interiérech Sweet Home 3D. Přináší celou řadu novinek. Zdůraznit lze možnost otevírání oken, dveří nebo skříněk. Zmínit lze také novou figurínu s otočnými klouby.

Ladislav Hagara | Komentářů: 20
12.10. 15:00 | Nová verze

Byla vydána nová verze 2018-10-09 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Přehled novinek v poznámkách k vydání. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Z novinek je nutno upozornit na odstranění programu Wolfram Mathematica.

Ladislav Hagara | Komentářů: 2
11.10. 22:44 | Zajímavý projekt

V rámci projektu PRIM (Podpora rozvíjení informatického myšlení), jehož cílem je "podporovat změnu orientace školského předmětu informatika z uživatelského ovládání ICT směrem k základům informatiky jako oboru", byly na stránkách iMyšlení (informatické myšlení) představeny volně stažitelné učebnice a výukové materiály pro výuku informatiky. Videozáznam z tiskové konference na Facebooku.

Ladislav Hagara | Komentářů: 2
11.10. 13:22 | Nová verze

Nadace Free Software Foundation (FSF) zveřejnila na svých stránkách prohlášení k připojení Microsoftu k Open Invention Network (OIN): Je to krok správným směrem. Problematiku softwarových patentů to ale neřeší. OIN pokrývá pouze část svobodného softwaru. Smlouvu s OIN lze vypovědět s 30 denní lhůtou. FSF vyzývá Microsoft, aby 1) jednoznačně potvrdil, že ukončil všechny patentové spory související s Linuxem v Androidu, 2) s členy OIN

… více »
Ladislav Hagara | Komentářů: 2
10.10. 22:22 | Komunita

Bradley M. Kuhn se v příspěvku na blogu Software Freedom Conservancy zamýšlí nad připojením Microsoftu k Open Invention Network. Žádá Microsoft, aby jako gesto dobré vůle a jako důkaz, že to myslí opravdu vážně, sám commitnul zdrojové kódy proprietárního patentovaného souborového systému exFAT pod licencí GPLv2+ do upstreamu Linuxu.

Ladislav Hagara | Komentářů: 32
10.10. 18:11 | Komunita

Microsoft se připojil k organizaci Open Invention Network, zkráceně OIN, založené v roce 2005 za účelem vytvoření a správy portfolia patentů, jeho sdílení a použití v patentových sporech k ochraně Linuxu a open source softwaru. Portfolio patentů se tím rozšířilo o více než 60 000 patentů.

Ladislav Hagara | Komentářů: 8
10.10. 15:25 | Zajímavý článek

Vědci z Národního ústavu duševního zdraví (NÚDZ) v Klecanech experimentálně zjistili (publikace v BioMed Research International), že používání GPS navigace v chytrých brýlích mění strukturu mozku. U testované skupiny došlo už po třech měsících ke snížení počtu spojení mezi hipokampem a ostatními částmi mozku.

Blaazen | Komentářů: 13
10.10. 08:55 | Komunita

Diskusi vyvolala stránka Flatpak - bezpečnostní noční můra (flatkill.org) popisující bezpečnostní problémy technologie Flatpak [reddit, Hacker News].

Ladislav Hagara | Komentářů: 80
Přispíváte osobně k vývoji svobodného softwaru?
 (40%)
 (41%)
 (23%)
 (22%)
 (10%)
 (37%)
Celkem 206 hlasů
 Komentářů: 7, poslední včera 22:28
Rozcestník

Dotaz: Ext4, 16TB HDD a 11 dnů běžící fsck

6.12.2017 11:45 Dramon
Ext4, 16TB HDD a 11 dnů běžící fsck
Přečteno: 2104×

Chtěl bych se zeptat, co si do budoucna počít s situací, kdy mi fsck nad ext4 LVM diskem běží již 11 dnů a nachází se ve fázi "1D", kdy to kontroluje překřížení souborů nebo tak něco a já jsem z toho celej nepříčetnej.
Už jen kvůli tomu, že když by to člověk zastavil a spustil znovu, tak to začíná od začátku.

Mám zahodit ext4 a přejít na XFS, které je pro RHEL 7 výchozí a tento problém se mi již nikdy nestane, protože například

  • XFS má rychlejší/chytřejší/více jader podporující fsck, resp.xfs_repair
  • XFS je na velká data prostě lepší

Nebo to dopadne tak, že až mi párkrát upadne server, tak se mi XFS rozbije tak, že z něho už nic nevytáhnu a bude pokoj :( ?

Díky předem všem, kteří mají dlouhodobou zkušenost s provozováním takto velkých (a větších :-)) dat, za pomoc.

Odpovědi

6.12.2017 12:03 dustin | skóre: 61 | blog: dustin
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
ext4 na datových discích nepoužíváme, ale máme 11TB pole nad XFS. Obsahuje deduplikovaný strom backuppc s cca půl miliardou souborů, SW RAID10 s 8 SATA disky. xfs_repair na tom trvá několik hodin, ale sežere přes 30GB RAM. Server má RAM dostatek (128GB), na starším s 8GB RAM jsme to řešili dočasným přidáním swapu na SSD. Při pomalém swapu na HDD by to bývalo trvalo dny.

Není problém zrovna v tom, že ta kontrola vyžrala paměť a jede do pomalého swapu? Nevím, jen se ptám, tohle byl konkrétně problém u nás.
6.12.2017 12:11 Dramon
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
RAM mám zabráno 500MB z 5 GB, vytížené je jedno jádro ze 4.
Když si zobrazím IO, tak to vlastně s HDD nic nedělá, jen si to šmrdolí s tím jedním jádrem a jednou za čas to vyhodí hlášku "Clone multiply-claimed blocks".
Stroj je jen odkladiště na druhý level záloh, takže kromě disků to je taková plečička. Ale můžu upgradovat :-)
Umí ten xfs_repair aspoň používat více jader?
6.12.2017 13:16 dustin | skóre: 61 | blog: dustin
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Nemyslím si. Ale jak píšu, veliký strom to dává za několik hodin.
6.12.2017 18:35 j
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
To ze to trva 11 dnu spis ukazuje na to, ze ten disk(y) neni uplne zdravej a snazi se dopocitavat data (mineno to LVMko). Tyhle chyby se objevujou trebas v situaci, kdy to natvrdo vytahnes z elektriky (na EXT).

Vic jader ti moc nepomuze, vzdycky ses omezenej IOps disku. Pricemz pri hromade pidisouboru se klidanko muzes dostat i pod 1MB/s per disk.
6.12.2017 18:46 Dramon
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Disky si myslím, že jsou fajn, minimálně SMART nic nehlásí a jsou relativně nové.

Když si pustím iostat, tak je vidět, že na disky to v podstatě vůbec nešahá.

8.12.2017 08:57 tomo_tn
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Zdravim,

ku tomu XFS - som za, pouzivam ho uz roky bez vacsich problemov, kedysi ked sa XFS s linuxom este len zacinalo kamaratit bolo mazanie malych suborov fakt bolestive, myslim ze sa mi ich podarilo skor nakopirovat ako zmazat :) To sa ale bavime o dobe kernelu 2.4. + externe patche pre XFS. Od tej doby sa vsetko velmi zmenilo, XFS sice stale nemaze tak ako ine FS ale zapis/ prechadzanie/ vyhladavanie su mnohokrat rychlejsie (poznamka nikdy nemazte vela suborov cez mc - to sa neda dockat). Na 2 stranu nieje problem mazat a zapisovat na disky naraz. Dalej XFS naozaj cachuje o106 takze pamat v pocitaci je aspon k niecomu -- mam 8GB a zriedkakedy sa dostanem nad 2GB vytazene aplikaciami. Na desktope sa po chvili prestane z HDD citat takmer uplne - vsetko uz je v RAM, obcasne bliknutie pola nieje ani pocut :)

Presiel som si z XFS tieto konfiguracie:

linux + sw raid cca 6 SCSI diskov, kernel 2.4.xx irix - desktop 6.5.2x linux + rw raid battery backed up chache 4 disky pouzivane ako desktop 4.12+

jedinky krat co sa mi nepodarilo cez xfs_repair FS znova rozchodit bol ten linux + sw raid v davnoveku. Ano XFS ked si nieje 100% isty konzistenciou suboru radcsej vyhodi 0 subor ako nieco potichu pokazene. Vtedy treba pouzit samozrejme zalohu. Inak je to FS co nahodis (pre polia je dobre si pozret vhodne mkfs.xfs prepinace a upravit si hodnoty podla seba)a neriesis, mal som 1-2 nahle vypadky napajania a system nabehol v pohode i data tam boli vsetky, ale ako hovorim mam desktop takze vecsinu casu je vsetko zapisane na platniach a nie niekde na pol ceste.
6.12.2017 13:17 Kandidat vied
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
odporucam JFS.
6.12.2017 16:09 Dramon
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Můžu poprosit o nějaké detaily, co se nevyčtou v manuálu, ale je nutné je získat praxí?
Třeba jak to zvládá velikosti v řádek desítek TB, jak rychlá je oprava, jak náchylné to je na rozsypání po tvrdém resetu, jak rychlé je fsck a jak bývají opravy úspěšné?

multi avatar 8.12.2017 16:37 multi | skóre: 38 | blog: JaNejsemOdsut
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Taktez doporucuji JFS. Prave z duvodu pomaleho FSCK u ext3 jsem presel na JFS.
svoboda je: když chci, tak můžu; kutilův web; bezdrátová čidla teploty vývoj softwaru
Heron avatar 13.12.2017 10:31 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Máte s tím někdo nějaké větší zkušenosti? Kdysi (to už bude víc jak 10 let), jsem to na doporučení kohosi vyzkoušel, (paralelně, to je asi podstatné), nakopíroval desítky GB dat a potom se to četlo asi tak 3MB/s a bylo slyšet, jak disky neustále seekují. Podotýkám, že to byly velké soubory (řádově GB) a na jiném FS se to četlo sekvenční rychlostí disku. Pro sebe jsem si z toho udělal ten závěr, že to má špatný alokátor a že to nedokáže správně rozmístit data na disku, pokud se jich tam kopíruje víc naráz.

Podotýkám, že z jednoho "testu" nedělám žádné závěry, dneska už JFS stejně používat nebudu (máme BTRFS a ZFS), ale jen mě to zajímá. (Už jen proto, že o tomto FS prakticky vůbec není slyšet.)
6.12.2017 14:48 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
XFS na velká data je lepší, horší je při práci s velkým množstvím malých souborů, obzvlášt mazání velkého množství malých souborů je výrazně pomalejší než u ext4. ALE. XFS má na druhou stranu hodně dat i metadat v RAM a naprosto nedoporučuji jej do situace bez UPS. Za posledních 10 let mě snad potkala jedna sitace s výpadkem a několik situací kdy se desktop "pověsil" a šel jen natvrdo vypnout Ext4 i v poslední době btrfs byly bez problémů, ale tohle je přesně situace, která může narušit XFS natolik, že nejenže oprava trvá dny ale nejde opravit vůbec, moje zkušenost. (nicméně to se mi s XFS stalo kolem roku 09 a dočetl jsem se, že ve FS byly v posledníczh letech velmi významné změny a proto tohle nemusi být relevantní informace)
6.12.2017 15:41 alkoholik | skóre: 36 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Neni to tak davno, kdy se XFS po fschecku po vypadku napajeni tvarilo OK, ale nektere soubory mely nulovou velikost.
6.12.2017 16:04 Dramon
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Tak tohle jsou přesně ty případy kterých se bojím, že nastanou :-(
S Ext mám zatím (uvidíme co bude, až mi fsck doběhne ;-)) dobré zkušenosti. Sice vypisuje romány, ale data jsou pak OK.

Stejně zvažuju nějaké automatické md5 buď do EA nebo do .MD5 souborů v adresáři. Že se něco poškodí mi ani tak nevadí, ale že nepoznám, že se to poškodilo, tak to vadí víc.

6.12.2017 16:52 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Sice vypisuje romány, ale data jsou pak OK.
Tak ti přeju pěkné počtení. Já při nasazení Ext4 obvykle skončil s hromadou souborů v adresáři /lost+found. A to ani zdaleka nešlo o diskové pole v řádech TB.
6.12.2017 17:02 Dramon
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Taky se mi to občas stalo, ale to mi kupodivu nevadí.
Víc mi vadí, když skončím úplně bez dat, nebo s nulovou velikostí atp. Čehož se bojím u XFS, jak psal někdo výše.

Matně si vzpomínám, že jsem již před lety někde XFS na zálohy měl a po nějaké době používání jsem jej formátoval pěkně "zpátečnicky" na ext3....

6.12.2017 17:07 Dramon
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Tak ne, díval jsem se do mé dokumentace a zemřelo to tenkrát na tom, že mi nedoběhl xfs_check do konce. OS byl 32bit s 4GB RAM, swap 8+GB a disk 4.5TB. Padalo to na out of memory, což jsem na těch 32bitech neměl moc jak řešit.

Ještě pro vysvětlení:
Pokud mi nějaký soubor chybí, odmažu staré zálohy a pustím to odznovu. Nic se neděje, nejsou to primární zálohy, kdy bych potřeboval bůh ví jakou délku do minulosti.
Pokud se ale smaže vše, znamená to tahat ty data přes internet, což u 16TB prostě trvá.

6.12.2017 17:11 dustin | skóre: 61 | blog: dustin
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Jo, ten xfs check RAM žere a na 32bitech to snadno mohlo dojet na limit.
Pavel 'TIGER' Růžička avatar 6.12.2017 16:45 Pavel 'TIGER' Růžička | skóre: 44
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Já osobně mám vyplou automatickou kontrolu pomocí fsck, při výpadku se server automaticky ukončuje a sleduji stavy disků, jakmile se dějě něco podezřelého, tak je měním. Občas pustím fsck manuálně a k překřížení souborů mi už roky nedošlo. Ale pravda, já mám jen 9TB.
6.12.2017 16:54 Dramon
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Plus mínus to mám stejně, ale rozšiřoval jsem pole a říkal jsem si, že než to resiznu, tak to zkontroluju.
Pustil jsem "fsck -n" a hlásilo mi to pár chybiček někde v kroku 3+. Tak jsem to debil pustil naostro a z pár chybiček jich bylo víc a hlavně se to již nenamountovalo a hlásí to problém s "ext2fs_test_block_bitmap". Což by se asi dalo opravit, ale fsck to neudělá, dokud nedojede celá kontrola do konce a to už právě trvá docela dlouho :-).

Použení pro příště je udělat LVM snapshot a když se to tak vysype, tak to raději zkopírovat na nově zformátovaný oddíl, než to kontrolovat.

6.12.2017 23:05 Petr
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Ptas se co si pocit do budoucna. Ext4 je mrtve, brtfs je alfa, xfs a jfs maji sve vyhody i nevyhody. U me pred lety nastala podobna situace, vyhledove jsem zacal rust co se tyce dat +-20 TB rocne. Ma volba padla tehdy na freebsd a zfs. Mam xx poolu v ruznych konfiguracich, nejvetsi pool ma 30TB dat v milionech (desitkach) malych souboru. Scrub na tomhle poolu trva vice nez den, po vypadku napajeni se pool mountuje necelych 15 minut a nasledny scrub na online poolu trva o neco dele. Disky pod tim vsim jsou sifrovane. Ram mam v kazdym storage 256GB. Jsou to nejake xeony, sas disky od wdc, ecc ramky. Mam vicero nodu, vicero lokalit. Replikace dat je pakarna ale staci. Zatim.
6.12.2017 23:09 Petr
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Sorry, tech souboru tam nejsou desitky milionu, ale jenom neco pres 2M.
7.12.2017 18:44 Andrej | skóre: 45 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
…brtfs je alfa…

Tohle má být omyl, překlep nebo obojí? Já tedy vím jen o Btrfs, který není "alfa" a používá se v mnoha "produkčních" systémech. Kde přesně je psáno, že je Btrfs "alfa"? V nějakém článku z roku 2009 to asi bude. Zhruba od roku 2011 mám všechna svá data na Btrfs, k naprosté spokojenosti. Checksumy, copy-on-write a vestavěný RAID (který po desetiletích marných pokusů konečně opravdu dělá to, co RAID slibuje) jsou natolik zásadní vlastnosti, že si bez nich těžko lze představit souborový systém vhodný "do budoucna".

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
7.12.2017 21:37 alkoholik | skóre: 36 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Jenze nekteri od fs cekaji, ze se dostanou k datum rychle.
7.12.2017 22:38 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
No to máš tak. Někteří čekají od FS, že jim nahlásí chyby, pokud nastane nejaký problém mezi diskem a pamětí díky kontrole checksumu. Nebo potřebují COW pro snapshoty. A pak jsou tací, kteří si bez této funkcionality nedovedou současný FS představit. Rychlost pro ně je pak otázka peněz. Třeba tak že budeš mít HW pole se SSD na infinibandu. Ale na Ext4 si snapshot a checksum nepořídíš za žádné peníze. Pokud ti absence těchto vlastností nevadí, tak je vše OK a můžeš využít rychlejší FS. (Jsou i jiní, kterým nevadí absence vlastností, které má standardní POSIX FS a používají FAT32. A myslím, že by v dost testech dosáhl i větších rychlostí na stejném HW než linuxový FS.)
Pavel 'TIGER' Růžička avatar 7.12.2017 23:52 Pavel 'TIGER' Růžička | skóre: 44
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Také jsou lidé, kterým je jedno, jaký FS jim tam běží, hlavně, že to funguje. Pravdou je, že FS se vybírá podle jeho nasazení a ne obliby daného uživatele.
Jendа avatar 8.12.2017 05:42 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Tento benchmark je zcela zjevně zfalšovaný a určitě k němu použili nějakou historickou distribuci, například Debian s prehistorickým jádrem 4.14 ve kterém btrfs opravdu mohlo být nepatrně pomalejší. Kdyby použili moderní distribuci s libovolným jádrem vydaným v posledních 50 letech, například 4.15-rc2, tak by věděli, že tam už žádné problémy nejsou. Dále je z naměřených dat (IOPS, propustnost) jasné, že používají SSD, čili write-only-memory, kterou by žádný normální člověk nepoužil na nic jiného než bcache. Kdyby použili kvalitní rotační disky, tak na žádný bottleneck nenarazí, protože btrfs jejich 100 IOPS a 180 MB/s naprosto bez problému pokryje. Obecně fakt, že si vůbec dovolili srovnat btrfs s archaickými filesystémy ukazuje, že si svých dat neváží a chtějí o ně přijít. Například když se jim stane silent data corruption, která se na každém desktopu stává minimálně 158742x za hodinu, tak budou žít v blahé nevědomosti, zatímco btrfs by je na to upozornil, teda pokud by kontrola checksum zrovna fungovala.<EOS>
rnn-andrej-gen finished, inference took 10.973 seconds. Memory used: 985 MB.
10.12.2017 06:43 Andrej | skóre: 45 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Lidé, kteří dlouho šíří různé kraviny — zejména pak popírači nových technologií, od parního stroje až po Btrfs —, občas zabřednou do vlastních žvástů a fantazií tak hluboko, že přestanou vnímat realitu a papouškují stále dokola otřepané fráze.

Povědomí o silent data corruption člověk získá teprve tehdy, pokud má zkušenosti s dost velkými systémy. Vtipní jsou zejména ti mudrcové, kteří v životě viděli všeho všudy něco mezi jedním desktopem a jedním rackem, ale zaručeně vědí, že silent data corruption se jich netýká. (Přesněji, nic o tom nevědí, protože tam mají Ext4 a věří v zázraky.)

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
10.12.2017 08:48 Peter Golis | skóre: 57 | Bratislava
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Sklamem ťa. Silent data corruption som zažil napríklad aj ja, a to bez racku. Bolo to v domácom segmente. Disky mi bez vyhlásenia chyby prečítali bloky dát s nulami, pôvodne boli v tých blokoch nenulové údaje.

V práci sa to u nás rieši s technológiami ktoré sa nespoliehajú že samotné disky by mali mať crc na blokoch.
Pavel 'TIGER' Růžička avatar 10.12.2017 09:45 Pavel 'TIGER' Růžička | skóre: 44
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Oproti parnímu válčí BTRFS není novou technologií je to jen další FS, který byl později napsán, nic víc.
14.12.2017 08:16 2017
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Proc se parni stroj tak rychle rozsiril a chtel ho kazdy?
14.12.2017 09:21 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
14.12.2017 17:52 pavele
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
A že jsme hodně postoupili v těch technologiích, že?

Zastaralý, předpotopní parní stroj s nízkou účinností, kde by se dnes ještě mohl používat?
16.12.2017 01:03 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Celkem postoupili. Účinnost moderních parních turbin v porovnání k účinnosti Carnotova cyklu nad vyměníky odpovídajích teplot není nijak moc špatná. (na rozdíl od pístových parních strojů.)
Heron avatar 13.12.2017 10:31 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Tve pozor, aby ti nepraskla cévka ;-)
10.12.2017 06:58 Andrej | skóre: 45 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Opravdu se dostanou rychle ke svým datům? Co třeba ke svým náhodně pozměněným datům?

Jiný benchmark dopadne třeba pro Btrfs o fous lépe.

"Výkon" v nějakém benchmarku není až tak podstatný. Otázka je, jestli srovnáváme srovnatelné technologie. Jak by asi dopadl Ext4 s CoW, checksumy, vestavěným RAIDem a dvěma kopiemi metadat? Inu, dopadl by na prdel, protože nic z toho neumí.

Kdyby byl Btrfs desetkrát pomalejší než Ext4, asi by to stálo za nějakou hlubší úvahu. Jenže on je Btrfs v některých bencharkových "disciplínách" srovnatelný, někde dvakrát až třikrát pomalejší a výjimečně tu a tam rychlejší. Otázka pak je, proč bych vůbec měl uvažovat o zoufalství zvaném Ext4 bez checksumů, CoW a opravdového RAIDu. Fakt to nedává smysl. Můžu si koupit rychlejší disk nebo SSD, ale ztracená data si zpátky nekoupím.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
k3dAR avatar 10.12.2017 18:23 k3dAR | skóre: 51
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
opravdovy RAID? BTRFS kteremu kdyz v RAID1 vypadne 1 disk ze 2, tak uz na to nelze(jeste nedavno neslo) zapisovat, to dava(lo) opravdu novy vyznam slovu mirror ;)
porad nemam telo, ale uz mam hlavu... nobody
Heron avatar 13.12.2017 10:33 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
"Výkon" v nějakém benchmarku není až tak podstatný. Otázka je, jestli srovnáváme srovnatelné technologie. Jak by asi dopadl Ext4 s CoW, checksumy, ...
Asi tak. Srovnávají se dvě zcela odlišné věci a někdo z toho pořád chce dělat nějaké závěry.
Jendа avatar 8.12.2017 05:33 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
který po desetiletích marných pokusů konečně opravdu dělá to, co RAID slibuje
Mně RAID slibuje, že systém nadále funguje i při selhání jednoho disku…
8.12.2017 10:15 j
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Myslis s tim vadnym diskem? Specielne pokud se bavime o SW raidu?
Jendа avatar 8.12.2017 13:12 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Samozřejmě. Prostě ho oflaguje za vadný a normálně dál funguje - buď dopočítává paritu (R5/6) nebo používá druhou kopii (R1).
10.12.2017 06:35 Andrej | skóre: 45 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Omyl. Chvíli dopočítává paritu, ale pak spustí resilvering a zničí všechna data.

Tohle už jsem psal asi tak stokrát: Zastaralý RAID se vypořádá pouze s totálním selháním (tedy de facto odpojením) jednoho disku, nikoliv s poškozením dat (více či méně náhodným) na jednom disku.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
8.12.2017 12:17 R
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Minule tu bolo, ze tato "feature" btrfs je uz fixnuta. Alebo nie? Skusat to nebudem...
10.12.2017 06:30 Andrej | skóre: 45 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Zastaralý RAID ale tento slib soustavně porušuje, což jsme řešili zhruba desetkrát, že ano. Nějak ses na těch jednoduchých faktech zaseknul a už mě celkem unavuje opakovat to stále dokola.

Zkus na RAIDu, který není integrovaný s filesystémem, přepsat celý jeden disk nulami, jen s výjimkou bloků s rádoby-RAID metadaty. Pak se uvidí, jestli ten systém opravdu ustojí (jakékoliv) selhání jednoho disku. Nápověda: Ne, neustojí; po čase spustí resilvering a zničí všechna data. ZFS nebo Btrfs v RAID konfiguraci to naopak ustojí, tedy kromě RAID0.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Jendа avatar 10.12.2017 11:02 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Zastaralý RAID se vypořádá pouze s totálním selháním (tedy de facto odpojením) jednoho disku, nikoliv s poškozením dat (více či méně náhodným) na jednom disku.
Tak ještě že scrub tohle odhalí. Ne, počkat, scrub nekontroluje všechna metadata. Tak zkusíme ten strom projít. Ne, počkat, to přečte náhodně jenom jednu kopii metadat a navíc to neumíme efektivně udělat když máme snapshoty. Fuck.
Zkus na RAIDu, který není integrovaný s filesystémem, přepsat celý jeden disk nulami, jen s výjimkou bloků s rádoby-RAID metadaty.
Proč bych to dělal? Proč místo toho radši nepřepsat kus paměti náhodnými daty nebo nespustit rm -rf --no-preserve-root /? Vybral sis jeden z žiliónu způsobů jak přijít o data, u kterého má zrovna btrfs docela dobrou šanci, že ho odhalí, a upnul ses na něj.
Jendа avatar 10.12.2017 11:13 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
(přesněji: scrub zkontroluje checksum bloku s metadaty, ale už nezkontroluje, že ta metadata dávají smysl, tj. třeba že to je pořád validní b-strom, že ty pointry neukazují třeba někam dopryč, že jsou pořád dosažitelné všechny soubory atd., prostě to co dělá fsck na ostatních filesystémech)
12.12.2017 21:32 honza
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Proč bych to dělal?
Protože přepsání jedné strany mirroru nulami nebo náhodnými daty je ve skutečnosti dost dobrý příklad toho, co se ve skutečnosti často děje. Obvykle je to nějaká varianta jednoho z následujících scénářů:

1) LUN, který je součástí mirroru někdo omylem připojí k jinému stroji, který na něj začne zapisovat.

2) LUN, který je součástí mirroru je vyexportovaný z nějakého inteligentního pole, které podporuje klonování LUN, různé snapshoty. No a "admin" se jednoho dne prostě uklikne a místo dalšího snapshotu udělá rollback, nebo si splete směr klonování...
Proč místo toho radši nepřepsat kus paměti náhodnými daty
Vytvořit prakticky nasaditelný (souborový) systém, odolný vůči tomuto vektoru je hodně težké, ale máte pravdu, bylo by krásné ho mít.
nespustit rm -rf --no-preserve-root /
Tak od toho jsou snapshoty, případně další věci jako immutable zony atp.
scrub zkontroluje checksum bloku s metadaty, ale už nezkontroluje, že ta metadata dávají smysl, tj. třeba že to je pořád validní b-strom, že ty pointry neukazují třeba někam dopryč, že jsou pořád dosažitelné všechny soubory atd.
Ano, předpokládáný model je, že souborový systém generuje správná data a ta se případně poškodí pozdějí (na disku, ale i v storage stacku, v transportu atd). U ZFS se předpokládá, že bloky se správným checksumem mají i správný obsah.

fsck u extN atp. musí kontrolovat konzistenci metadata sémanticky, protože nemá jiný způsob, jak ověřit, že jsou správná. To sebou samozřejmě nese mnoho problém - to že nějaký blok vypadá jako uzel b-stromu ještě nemusí nutně znamenat, že to je opravdu správný a aktuální uzel toho správného b-stromu atd.

Samozřejmě, že se může stát (a stává), že je chyba v kódu ovladače souborového systém, ta se ale hladá jinak a jinými nástroji. Když v produkci pomocí fsck zjistíte, že místo b-stromu ovladač vygeneroval graf s cyklem, stejně s tím už toho reálně mnoho nenaděláte.
Jendа avatar 12.12.2017 22:30 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
1) LUN, který je součástí mirroru někdo omylem připojí k jinému stroji, který na něj začne zapisovat.
Tady přesně dojde k té situaci, že jiný stroj zapsal na btrfs blok s validním checksumem, takže FS je nekonzistentní a nikdo se to nedozví, ne?
2) LUN, který je součástí mirroru je vyexportovaný z nějakého inteligentního pole, které podporuje klonování LUN, různé snapshoty. No a "admin" se jednoho dne prostě uklikne a místo dalšího snapshotu udělá rollback, nebo si splete směr klonování...
Opět, rollbacknutý snapshot obsahuje bloky s validním checksumem…
13.12.2017 08:34 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
1) LUN, který je součástí mirroru někdo omylem připojí k jinému stroji, který na něj začne zapisovat.
Tady přesně dojde k té situaci, že jiný stroj zapsal na btrfs blok s validním checksumem, takže FS je nekonzistentní a nikdo se to nedozví, ne?
Pokud vím, tak Btrfs není síťový souborový systém, takže by mne docela zajímaly bližší okolnosti, jak by k tomu mohlo dojít.
13.12.2017 15:44 honza
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
FC, iSCSI, IB, atd. dříve klidně i paralelní SCSI sběrnice sdílená více stroji
13.12.2017 19:10 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Ovšem v takovém případě se nabourá každý souborový systém, co není určen pro clusterové nasazení. V takovém případě máte použít Cephfs, GlusterFS, OCFS2 nebo GFS2. Pokud použijete pro takový účel FS typu ZFS, nebo Btrfs tak si vědomě koledujete o ztrátu dat a nic jiného si ani nezasloužíte.
Jendа avatar 13.12.2017 21:40 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Ovšem v takovém případě se nabourá každý souborový systém
Celou dobu tu neřešíme, jestli se FS nabourá, ale jestli se na to přijde. U MD s „klasickým“ FS se na to opravdu přijít nemusí.
Pokud použijete pro takový účel
Prosím přečti si ještě jednou ~3 příspěvky před tvojí reakcí. Bavíme se o omylu, ne o záměrném použití.
13.12.2017 15:42 honza
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Zjednodušeně řečeno: ZFS je strom, jehož každý uzel (~ datový blok na disku) v sobě nese checksumy všech svých přímých potomků.

Pokud je ZFS aktivní, kořen stromu je v paměti (tedy i checksumy jeho dětí). Když chci projít strom, začnu v kořenu a podívám se, kde leží jeho dítě (blok), kterým potřebuju projít. Načtu ho z 1. disku v mirroru, spočítam jeho checksum a porovnám s tím, co mám uloženo jako očekávanou hodnotu v kořenu. Pokud checksum nesouhlasí, přečtu ten samý blok z 2. disku v mirroru a opět ověřím checksum. Pokud je to checksum tentokrát ok, rovnou přepíšu blok 1. disku obsahem z toho 2 (ZFS tomu říká self-healing). Teď mám v ruce zaručeně validní blok/uzel stromu, jehož kořen mám v paměti. Zase obsahuje adresy a checksumy svých dětí, takže zase zvolím jeden disk z mirroru, přečtu blok, ověřím checksum, případně přečtu odjinud a opravím atd atd dokud nedojdu do souboru, který jsem chtěl přečíst.

Pokud ZFS není aktivní a něco špatného se stane s některým diskem, je to trochu složtější, opět zjednodušeně řečeno: změny v ZFS probíhají v transakcích, při každé transakci se vytvoří nový strom (s novým kořenem), na discích tedy najednou existují stovky stromů (ne všchny jsou samozřejmě kompletní). Při importu (aktivaci ZFS) musím vybrat ten správný, tj. co nejnovější, ale současně nepoškozený a použitelný kořen. Pokud někdo "rollbackne" jeden disk, kořeny uložené na něm budou "starší" než kořeny uložené na ostatních discích, takže nejspíš nevyhrají v testu "novosti". Každý kořen ZFS stromu checksumuje sám sebe, což je takový rychlý test proti přepsání části disku nulami nebo nějakým nepořádkem, dál se testuje, že je z kořene správně vidět alespoň začátek stromu. Správně by bylo samořejmě potřeba ověřit dostupnost všech uzlů, to by ale trvalo neúnosně dlouho, takže se to dělá jen u opravdu hodně poškozených ZFS poolů.
13.12.2017 19:37 dustin | skóre: 61 | blog: dustin
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Je vidět, že o tom něco docela víš. Díky moc za užitečné info.
Jendа avatar 13.12.2017 21:46 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Díky za info. Furt nejsem moc přesvědčen, že může nastat situace 1 (RAIDy se proti připojení v degradovaném režimu docela brání a typicky je potřeba opravdu ručně potvrdit, že tam fakt chci zapisovat) a pro situaci 2 má MD taky časové značky. (čti: ještě se mi taková chyba ani jednou nepodařila :)
14.12.2017 08:11 dustin | skóre: 61 | blog: dustin
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Degradované md raid1 provozuji zcela standardně (i root), používáme to pro replikaci zálohovacího serveru na offline záložní disky. S montováním není žádný problém a nevzpomínám si, že bych to někde povoloval. Mám to i na embedded x86 routeru, kde jsem ještě nedodal druhý disk, takže běží systém na degradovaném md raid1 (U_)
7.12.2017 18:29 Andrej | skóre: 45 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Mám zahodit ext4…

Ano.

…a přejít na XFS…

Ne.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
9.12.2017 06:29 cronin | skóre: 49
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Táto rada vedie tak nejako do slepej uličky. Čo teda navrhuješ použiť a prečo?
10.12.2017 06:31 Andrej | skóre: 45 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck

Btrfs nebo ZFS.

Protože je rok 2017.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Pavel 'TIGER' Růžička avatar 7.12.2017 22:26 Pavel 'TIGER' Růžička | skóre: 44
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Já osobně jsem zkoušel různé FS, v různých fázích vývoje. Nemám asi vyzkoušené nejnovější verze. Ale z různých důvodů jsem se vždycky vrátil k EXTx.
8.12.2017 12:32 Trubicoid2
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Xfs bych se nebál, xfs_repair je skutečně multithreaded, navíc se sám nepustí, samo se dělá jen rychlá kontrola při mountu (je to v jádře). Podle mě je xfs robustní a hodí se právě na obrovská pole s velkýma souborama.
10.12.2017 09:31 honza
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Doporučoval bych přejít na nějaký moderní soborový systém, např. ZFS.

Fsck (v ZFS světě se tomu říká scrub) na ZFS může taky nějakou dobu trvat, nijak zvlášť to ale nevadí, protože souborový systém je během scrubu namountovaný read-write a k datům je možné normálně přistupovat.

ZFS používá kontrolní součty, takže pozná, že jsou (meta)data poškozená.Díky tomu scrub nepadá do různých podivných nekonečných cyklů, ve kterých mají tendenci končit fsck pro UFS, extN a podobné systémy (což je možná to, co se stalo teď vám).
10.12.2017 16:04 vasek
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Jen pozor na to, že ani ZFS není všespásný. Ze všech FS co jsem kdy používal se mi ZFS poškodilo nejvíce. Když vezmu různé výpadky proudu, HW problémy s řadiči apod., tak třeba ext3/4 se dokázal vyhrabat i z toho, kdy se rozbitý HW raid 5 špatně několikrát poskládal, čehož výsledkem hodně souborů skončilo v /lost+found, ale FS to přežil i s většinou dat. XFS se mi rozbilo v minulosti hodněkrát kvůli výpadku proudu ... respektive hodně souborů vynulovaných nebo nešel FS opravit. Poslední dobou (RHEL 7) se mi to abych pravdu řekl zatím nestalo (musím zaklepat). ZFS se mi v minulosti rozbil tak, že ve FreeBSD nešel namontovat ani opravit (oprava končila pádem OS). Nakonec pomohla nějaké live distribuce solarisu a tajný přepínač -X u repairu při zpool importu. Vinou byl sice HW problém, který ale luxusně ZFS rozbil.

Btrfs osobně nepovažuji za něco, co by se dalo jako FS používat. S ním jsem už skončil. Na linuxu jsem ho párkrát zkoušel, ale po pár hodinách či dnech se to vždy rozsypalo (stačilo zapnout nějakou featuru jako kompresi aj.)...
10.12.2017 16:49 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
No, s takovou bych ti nesvěřil ani budíka. Taky by se nejspíš rozbil.
10.12.2017 17:15 alkoholik | skóre: 36 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Naopak! Takove lidi je treba zamnestnavat jako testery.
10.12.2017 18:59 vasek
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
To už mi pár lidí říkalo :) Jsem totiž "klikař", který z 10 výrobků, které koupí má 9 vadných. Poslední dobou docela často plním github s různými issues v různých projektech. Než něco nakonfiguruji, obvykle koukám do zdrojáků (dost věcí není dokumentovaná) a dotáhl jsem to tak daleko, že daný SW nemusím ani spouštět a už v kódu narážím na nějaké chyby, které by mi mohli vadit v provozu :)
11.12.2017 15:58 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
No pokud pravidlo pro používání výrobků je skutečně takové, že používání znamená test odolnosti, tak se není co divit. Protože používat komplexní file systémy (jako bezesporu ZFS a XFS jsou) bez toho, že si zajistím dost bezpečně, abych se na HW mohl skutečně spolehnout. Což výpadky proudu skutečně nejsou. Já třeba ted na jednom nepodstatném FS řeším nějaké neopravitelné chyby v btrfs srubu, ale vím že jsem si je v podstatě způsobil sám, hraní si s přetaktováním s paměťmi, které nejsou ECC může udělat chyby. (Podobně bych ZFS bez ECC pamětí asi nikdy nepustil na produkčním systému.)
11.12.2017 16:15 vasek
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Právě, že použití je v podstatě klasické. Většinou značkové servery buď za UPS nebo v data centrech se zálohovaným napájením. Výpadky proudu jsem zažíval či zažívám většinou na vlastním železe (desktop ...).
11.12.2017 16:53 pavele
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Taky jsem si při nahlášeném výpadku proudu říkal, že mám UPS.

Tak server měl UPS, ale baterka klekla 3 dny před výpadkem.

Takže jsem si otestoval tvrdý výpadek s virtuály na ext4 a xfs.

Vždy je třeba počítat s nejhorší variantou a nespoléhat na to, že:

- vždyť mám UPS, výpadek mi nevadí,

- můžu si dovolit fs, který má problémy při výpadku proudu. :-)

Pavel 'TIGER' Růžička avatar 11.12.2017 22:38 Pavel 'TIGER' Růžička | skóre: 44
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Tou kleklou baterkou bych se moc nechlubil ... je to něco podobného, jako nesledovat stav disků. V dnešní době ale platí víc, než kdykoliv jindy že čím více záloh, tím více jsou data v bezpečí.
10.12.2017 22:19 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Tak to máš teda pravdu.
11.12.2017 10:07 hydrandt | skóre: 35 | blog: Kanál | Šanghaj
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
:-D

Taky si rikam, ze asi ziju v nejakem alternativnim universu (nastesti).
I am Jack's wasted life.
10.12.2017 21:17 Odin
Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
Doporucuji btrfs. Umi snapshoty, je rychly a dostatecne stabilni. Provozuji nekolik let bez problemu.

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.