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

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 27
včera 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
včera 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 6
včera 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
14.12. 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 6
14.12. 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
14.12. 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
14.12. 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
14.12. 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
14.12. 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 997 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

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

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

    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. 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. 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. 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. 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. 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. 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. 13:17 Kandidat vied
    Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
    odporucam JFS.
    6.12. 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. 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. 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. 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. 15:41 alkoholik | skóre: 35 | 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. 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. 16:52 Aleš Kapica | skóre: 46 | 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. 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. 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. 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. 16:45 Pavel 'TIGER' Růžička | skóre: 41
    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. 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. 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. 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. 18:44 Andrej | skóre: 44 | 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. 21:37 alkoholik | skóre: 35 | 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. 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. 23:52 Pavel 'TIGER' Růžička | skóre: 41
    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. 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.
    Why did the multithreaded chicken cross the road? to To other side. get the
    10.12. 06:43 Andrej | skóre: 44 | 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. 08:48 Peter Golis | skóre: 55 | 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. 09:45 Pavel 'TIGER' Růžička | skóre: 41
    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. 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. 09:21 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Ext4, 16TB HDD a 11 dnů běžící fsck
    14.12. 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?
    dnes 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. 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. 06:58 Andrej | skóre: 44 | 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. 18:23 k3dAR | skóre: 47
    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. 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. 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…
    Why did the multithreaded chicken cross the road? to To other side. get the
    8.12. 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. 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).
    Why did the multithreaded chicken cross the road? to To other side. get the
    10.12. 06:35 Andrej | skóre: 44 | 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. 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. 06:30 Andrej | skóre: 44 | 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. 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.
    Why did the multithreaded chicken cross the road? to To other side. get the
    Jendа avatar 10.12. 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)
    Why did the multithreaded chicken cross the road? to To other side. get the
    12.12. 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. 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…
    Why did the multithreaded chicken cross the road? to To other side. get the
    13.12. 08:34 Aleš Kapica | skóre: 46 | 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. 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. 19:10 Aleš Kapica | skóre: 46 | 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. 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í.
    Why did the multithreaded chicken cross the road? to To other side. get the
    13.12. 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. 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. 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 :)
    Why did the multithreaded chicken cross the road? to To other side. get the
    14.12. 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. 18:29 Andrej | skóre: 44 | 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. 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. 06:31 Andrej | skóre: 44 | 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. 22:26 Pavel 'TIGER' Růžička | skóre: 41
    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. 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. 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. 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. 16:49 Aleš Kapica | skóre: 46 | 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. 17:15 alkoholik | skóre: 35 | 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. 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. 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. 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. 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. 22:38 Pavel 'TIGER' Růžička | skóre: 41
    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. 22:19 Aleš Kapica | skóre: 46 | 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. 10:07 hydrandt | skóre: 34 | 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. 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.