abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:33 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na jednodeskový počítač Renegade Elite. Měl by být 4x výkonnější než Raspberry Pi 3 Model B+. Vlastnit jej lze již v září. Aktuální cena je 99 dolarů.

Ladislav Hagara | Komentářů: 6
včera 12:44 | Komunita

Od 7. do 10. června proběhla v Berlíně Linux Audio Conference 2018. Na programu byla řada zajímavých přednášek, seminářů a vystoupení. Videozáznamy lze zhlédnout na media.ccc.de.

Ladislav Hagara | Komentářů: 0
včera 09:44 | Pozvánky

Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.

xkucf03 | Komentářů: 0
14.7. 22:44 | Nová verze

Bylo oznámeno vydání KDE Frameworks 5.48.0, tj. nové verze aktuálně 72 knihoven rozšířujících multiplatformní framework Qt. Řešena je mimo jiné bezpečnostní chyba CVE-2018-10361 v KTextEditoru zneužitelná k lokální eskalaci práv. Knihovny KDE Frameworks jsou dnes využívány nejenom KDE Plasmou a KDE Aplikacemi.

Ladislav Hagara | Komentářů: 5
14.7. 20:11 | Nová verze

Byl vydán Debian 9.5, tj. pátá opravná verze Debianu 9 s kódovým názvem Stretch. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Předchozí instalační média Debianu 9 Stretch lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 13
13.7. 23:55 | Komunita

V Národní technické knihovně (NTK) je 150 nových počítačů s operačním systémem Linux, konkrétně s linuxovou distribucí Fedora. Do konce prázdnin si na nich lze zahrát počítačovou hru Factorio (Wikipedie). V pondělí 23. 7. proběhne LAN party s vývojáři této hry.

Ladislav Hagara | Komentářů: 0
13.7. 17:33 | Zajímavý software

Fanatical (Wikipedie) má ve slevě řadu počítačových her běžících také na Linuxu. Balíček her Fanatical Strategy Bundle lze koupit za 1,99 eur.

Ladislav Hagara | Komentářů: 1
13.7. 11:44 | Zajímavý software

Byla vydána počítačová hra Warhammer 40,000: Gladius - Relics of War běžící také na Linuxu. Koupit ji lze na GOG, Humble Store i na Steamu. Videoukázka na YouTube.

Ladislav Hagara | Komentářů: 0
13.7. 10:33 | Komunita

Guido van Rossum, původní tvůrce a doposud vedoucí projektu Python, oznámil, že opouští svou roli, tedy již se nebude podílet na tvorbě PEP a výběru hlavních vývojářů, odchází na odpočinek a do budoucna bude nejvýše řadovým přispěvatelem. Situace vyplynula mj. z procesu schvalování PEP 572.

Fluttershy, yay! | Komentářů: 4
12.7. 17:22 | Nasazení Linuxu

Článek na OMG! Ubuntu! představuje vesmírného interaktivního asistenta CIMON (Crew Interactive Mobile CompaniON) vyvinutého ve spolupráci firem Airbus a IBM. Uvnitř této osmikilogramové koule s osmipalcovým displejem běží Ubuntu. Více ve videu na YouTube.

Ladislav Hagara | Komentářů: 7
Jak čtete delší texty z webových stránek?
 (77%)
 (20%)
 (5%)
 (7%)
 (2%)
 (10%)
Celkem 354 hlasů
 Komentářů: 40, poslední 29.6. 10:21
    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: 2095×

    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: 61 | 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: 61 | 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: 74 | 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.
    Procesor je napájený přímo ze sítě a používá i její takt.
    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: 56 | 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: 61 | 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: 50
    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: 74 | 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…
    Procesor je napájený přímo ze sítě a používá i její takt.
    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: 74 | 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).
    Procesor je napájený přímo ze sítě a používá i její takt.
    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: 74 | 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.
    Procesor je napájený přímo ze sítě a používá i její takt.
    Jendа avatar 10.12.2017 11:13 Jendа | skóre: 74 | 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)
    Procesor je napájený přímo ze sítě a používá i její takt.
    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: 74 | 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…
    Procesor je napájený přímo ze sítě a používá i její takt.
    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: 74 | 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í.
    Procesor je napájený přímo ze sítě a používá i její takt.
    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: 74 | 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 :)
    Procesor je napájený přímo ze sítě a používá i její takt.
    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: 61 | 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.