git.kde.org mělo narušená data. Díky šťastné náhodě jsou data zachráněna

Blog Jefferai.org informuje o velkém narušení dat (data corruption) ke kterému došlo 22.3. a bylo rozšířeno i na mirrory tohoto serveru. Šťastnou náhodou byl jeden ze serverů v době narušení dat odstaven a zachoval tak neporušená data. Autor článku na tomto příkladu ukazuje, že git není tak bezpečný, jak jeho původní autor Linus uvádí. Na závěr autor uvádí nový způsob zabezpečení dat v KDE.

24.3.2013 19:37 | Jakub Lucký | Zajímavý článek

Komentáře

[jnml]

FUJ FUD!

Mirroring dělal přesně co měl. Jestli nemají normální zálohy a myslí si, že mirroring je zálohování, pak mají co si zaslouží.

[Heron]

+1

[xvasek]

Přesně tak - kde se flákala záloha? Pokud nic takového nemají, tak jsou to pěkní amatéři. A zadruhé - pokud je to v gitu, tak to musí mít (u KDE konkrétně) asi tak několik tisíc lidí někde u sebe, ne?

[danaketh]

+(dosaď si dostatečně vysoké číslo)

Tohle je celý facepalm jak prase. Člověk by čekal úplně jinej přístup, když svoje vlastní pitomosti denně zálohuje, kontroluje konzistenci a tak vůbec...

[pavlix]

Od příkazu git clone --mirror se očekává kopie obsahu celého repozitáře. Zálohy zřejmě mají. Ten člověk se nebál o pár dní starý stav repozitářů, ale o jejich nejposlednější stav, který jaksi mirrory neřeší. A zřejmě objevil nebezpečný rozpor mezi tím, co tvrdí Linus a co se v Gitu při této akci skutečně děje.

V případě, že by se toto nechytilo, tak by to nebyla až taková trága, ale způsobilo by to hromadu nepříjemností ohledně nahánění aktuálního stavu projektu.

[little.owl]

A zřejmě objevil nebezpečný rozpor mezi tím, co tvrdí Linus a co se v Gitu při této akci skutečně děje.

A v cem vidis ten rozpor?

To ze git clone --mirror neprovadi fsck automaticky je snad dobre, trva to vecnost, a je na spravcich repositare zajistit integritu repository pred jejim naklonovanim.

[pavlix]

A v cem vidis ten rozpor?

V tom, že značně přehání, když říká, že se o to nikdy nemusíš starat, a že to Git vždy kontroluje sám.

To ze git clone --mirror neprovadi fsck automaticky je snad dobre, trva to vecnost, a je na spravcich repositare zajistit integritu repository pred jejim naklonovanim.

To nerozporuju.

[little.owl]

Linux rekl, jak je spravne citovano na blogu, nasledujici:

If you have disc corruption, if you have RAM corruption, if you have any kind of problems at all, git will notice them. It’s not a question of if. It’s a guarantee. You can have people who try to be malicious. They won’t succeed. You need to know exactly 20 bytes, you need to know 160-bit SHA-1 name of the top of your tree, and if you know that, you can trust your tree, all the way down, the whole history. You can have 10 years of history, you can have 100,000 files, you can have millions of revisions, and you can trust every single piece of it. Because git is so reliable and all the basic data structures are really really simple. And we check checksums.

[Sten]

Trochu to zní jako FUD, ale není to tak, Jeff to tam taky popisuje. git clone --mirror dělá přesně to, co se od něj očekává. Proto není dobré mít zálohy Gitu přes git clone --mirror.

Btw. nikdy jsem --mirror nepoužíval. Nikdy jsem nepochopil, k čemu je dobré vypnout ochrany, které potom akorát způsobí, že vývojáři si takto propagované změny už třeba ani nepullnou. Naopak, pokud mirror se zapnutými ochranami odmítne udělat pull, ihned to upozorní, že někdo si hrál a rozbil main repository nebo že je tam vadný hardware (force push je zlo, správně se takové chyby opravují přes merge -s ours). Celý systém s anongitem by měl navíc používat dvoustupňový clone: samotný mirror by měl být clonován bez --mirror a teprve z něj by měl být anongit lokálně clonován s --mirror.

[pavlix]

Trochu to zní jako FUD, ale není to tak, Jeff to tam taky popisuje. git clone --mirror dělá přesně to, co se od něj očekává. Proto není dobré mít zálohy Gitu přes git clone --mirror.

Pokud ho správně chápu, tak v tom není žádný problém, když se explicitně používá git fsck. Navíc Jeff zřejmě očekával od --mirror i tu kontrolu.

Btw. nikdy jsem --mirror nepoužíval.

Bez --mirror se ti nekopírují všechny větve. Alternativou k němu je jen něco ve stylu rsync (ten navíc kopíruje i konfiguraci repozitáře, což může a nemusí být to, co chceš).

Nikdy jsem nepochopil, k čemu je dobré vypnout ochrany, které potom akorát způsobí, že vývojáři si takto propagované změny už třeba ani nepullnou.

V tomto případě se nejedná o vypnutí ochran, ale o jejich absenci.

Naopak, pokud mirror se zapnutými ochranami

Čemu říkáš mirror se zapnutými ochranami?

odmítne udělat pull, ihned to upozorní, že někdo si hrál a rozbil main repository nebo že je tam vadný hardware

Tady jsi úplně na jiné úrovni,

git pull

pracuje s větvemi, ne s repozitáři.

Celý systém s anongitem by měl navíc používat dvoustupňový clone: samotný mirror by měl být clonován bez --mirror a teprve z něj by měl být anongit lokálně clonován s --mirror.

Tak tohle už je pořádná blbost. Když uděláš klon s --mirror, tak přijdeš o data (ostatní větve). Následné použití --mirror už ti je pochopitelně nevrátí.

[Sten]

Bez --mirror se ti nekopírují všechny větve. Alternativou k němu je jen něco ve stylu rsync (ten navíc kopíruje i konfiguraci repozitáře, což může a nemusí být to, co chceš).

Ale zkopírují, pouze se nezaloží lokálně:

git pull
From ssh://my.serv.er/git/project.git
 * [new branch]      blabla -> origin/blabla
Already up-to-date.

Ale všechny commity jsou zkopírované a máte tedy kompletní zálohu.

V tomto případě se nejedná o vypnutí ochran, ale o jejich absenci.

Jde o vypnutí. Při git pull, pokud repozitář nebyl založen pomocí git clone --mirror, tam totiž jsou.

Čemu říkáš mirror se zapnutými ochranami?

Mirror server vytvořený pomocí git clone místo git clone --mirror.

pracuje s větvemi, ne s repozitáři

Ne, git pull sice aktualizuje jen aktuální lokální větev, ale z repozitářů stahuje všechny změny (ve výchozím nastavení). Ostatně je to napsané i v manuálu.

Tak tohle už je pořádná blbost. Když uděláš klon s --mirror, tak přijdeš o data (ostatní větve). Následné použití --mirror už ti je pochopitelně nevrátí.

git clone naklonuje všechny větve i bez --mirror, pouze je nezakládá lokálně. Ty větve ale pořád jsou stažené a jdou kdykoliv lokálně vytvořit pomocí git checkout větev. Ten anongit by se teda musel udělat trochu jinak, aby se donutil zakládat lokálně větve z původního serveru: git clone --reference lokální_kopie --mirror originální_server.

[pavlix]

Ale zkopírují, pouze se nezaloží lokálně:

A jo, pravda, ty commity se stáhnou, díky za upřesnění.

Jde o vypnutí. Při git pull, pokud repozitář nebyl založen pomocí git clone --mirror, tam totiž jsou.

Ne. Ještě teď jsem si zkontroloval manuálovou stránku a u --mirror se nepíše nic o tom, že by sloužilo k vypínání jakýchkoli ochran a dokonce ani ten vedlejší efekt tam není popsaný. Takže skutečně nikoliv.

Ten anongit by se teda musel udělat trochu jinak, aby se donutil zakládat lokálně větve z původního serveru: git clone --reference lokální_kopie --mirror originální_server.

Podle dokumentace je --reference jen optimalizace při použití více lokálních repozitářů, nic víc. Nejspíš by pomohlo, kdyby Git umožňoval alespoň volitelně kontrolovat stahované commity.

[Sten]

Ne. Ještě teď jsem si zkontroloval manuálovou stránku a u --mirror se nepíše nic o tom, že by sloužilo k vypínání jakýchkoli ochran a dokonce ani ten vedlejší efekt tam není popsaný. Takže skutečně nikoliv.

it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository

Pokud to přepisování není povoleno, tak si ten mirror všimne, že nově stažená data historicky nenavazují na místní a odmítne se synchronizovat.

Druhá možnost je zapnout transfer.fsckObjects.

Podle dokumentace je --reference jen optimalizace při použití více lokálních repozitářů, nic víc. Nejspíš by pomohlo, kdyby Git umožňoval alespoň volitelně kontrolovat stahované commity.

Ano, a ten referencovaný repozitář, pokud nebude klonovaný s git clone --mirror, to už bude hlídat.

[pavlix]

Pokud to přepisování není povoleno, tak si ten mirror všimne, že nově stažená data historicky nenavazují na místní a odmítne se synchronizovat.

Nevidím souvislost.

Druhá možnost je zapnout transfer.fsckObjects.

To zní jako řešení.

Ano, a ten referencovaný repozitář, pokud nebude klonovaný s git clone --mirror, to už bude hlídat.

Drbání levou nohou za pravým uchem.

[little.owl]

Nechapu. Zkopiruje to repository as-is, proste to prepise vsechno, i s chybama.

--mirror

Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository.

--bare

Make a bare GIT repository. That is, instead of creating (directory) and placing the administrative files in (directory)/.git, make the (directory) itself the $GIT_DIR. This obviously implies the -n because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created.

[pavlix]

Nechapu.

Nechápu, co nechápeš.

[asdfsadf]

No spis to vypada ze "nove, uzasne" ext4 opet ztraci/nici data. Coz ale pravda, git by to mel kontrolovat.

[Luk]

ext4 není ani nový, ani úžasný. Spíš je to snaha zachovávat maximum kompatibility s něčím velmi obstarožním.

[little.owl]

No spis to vypada ze "nove, uzasne" ext4 opet ztraci/nici data.

Blabol, ext4 je OK.

Z clanku neni jasne receno co je pricinou, jaky kernel ci HW pouzivaji a naopak z celeho pribehu kouka amaterismus spravcu KDE.

[pavlix]

Já bych to viděl spíše tak, že se ten člověk jen nedokázal jasně vyjádřit.

[Aleš Kapica]

Ne. Bohužel ext systémy nejsou ok. Několikrát mne postihla podobná věc. Způsob jakým fsck opraví souborový systém vede mnohdy k rozbití systému.

[Luboš Doležel (Doli)]

Já obvykle viním virtualizaci. Nikdy mě poškození ext* za běhu nepotkalo, a to používám i ext4, až teprve na virtualizovaných serverech Ábíčka před ~2 lety (ext3).

[Aleš Kapica]

V tom je podle mě zakopaný pes. Ext systémy spoléhají na fyzické zařízení. Bohužel u virtualizace není pod souborovým systémem obvykle fyzické zařízení, ale nějaká jiná vrstva - i víc, na které ovšem nikdy nelze na 100% spoléhat. U jiných souborových systémů se pracuje s daty jinak. Data jsou obvykle poházená všude možně zajišťují konzistenci dat na více místech. I je lze pochopitelně rozbít, ale výsledek opravy je úplně někde jinde.

Typické je to u toho gitu. Pokud je nějaký objekt poškozen, tak se dá opravit, pokud víme který to je. Jenže v případě ext systémů skončí poškozené soubory na jedné valné hromadě, očíslované podle inodů kde byly. Je téměř nemožné zjistit kam vlastně patří a o jaké soubory šlo. Natož ještě zjistit jak se původně jmenovaly.

[JoHnY2]

No porad je to lepsi pristup nez ZFS, kde kdyz dojde k poskozeni, tak se clovek muze jit klouzat. Recovery ma jen jeden krok: obnoveni ze zalohy. na druhou strani neexistuje bitrot a fs da vzdycky vedet o cemkoliv poskozenym a to velmi hlasite.

V tomhle me docela potesilo btrfs, ktery ma pro recovery docela extremni tooly vcetne moznosti dumbu cely struktury hashe nehashe. Proste to z disku vytahne co muze.

[little.owl]

Presne tak. Nekteri kolegova appliste tvrdojisne pouzivaji na serverech FreeBSD nebo OpenSolaris se ZFS a zpusob jakym to krachuje znamena velmi casto ztratu dat; zejmena pokud mate malo pameti (8GB a tak).

[little.owl]

Ext systémy spoléhají na fyzické zařízení.

Google pouziva na svych serverech ext4 (Irsko), ale pokud vim maji vyladeny custom firmware v discich; netusim v cem se lisi.

[bogo]

V tom je podle mě zakopaný pes. Ext systémy spoléhají na fyzické zařízení. Bohužel u virtualizace není pod souborovým systémem obvykle fyzické zařízení, ale nějaká jiná vrstva - i víc, na které ovšem nikdy nelze na 100% spoléhat.

Jiste, jenomze to neni chyba Ext. To je chyba te vrstvy ktera tvrdi ze umi sync, a pritom ho neumi (plus chyba spravce ze na tydle veci spoliha a/nebo o jejich omezenich nevi). Kdyz vam blokova vrstva tvrdi ze neco provede a pak to neprovede, neudela s tim ext* vubec nic (stejne tak zfs nebo jakykoliv jiny *fs).

Data jsou obvykle poházená všude možně zajišťují konzistenci dat na více místech.

LOL, pobavil.

[Aleš Kapica]

To je fajn že ses pobavil. Těm co takhle přišli o data moc do smíchu není. Ono totiž v případě git repozitáře je lepší varianta mít data poškozená, než je mít někde jinde než mají být.

[little.owl]

Jenze vy michate hodinky a holinky.

Ten problem je skutecne se sync a s tim kdy a jak se data fyzicky zapisi na medium, tedy s FW, disk driverem a celym block layer, ktere jsou pod FS, a s tim ext4 moc neudela. To je jeden z duvodu proc si velci odberatele a uzivatele disku nechavaji upravovat FW na miru (vim o Google, HP, Amazon), vyrobci si totiz vykladaji SATA standard a APM nekdy sverazne po svem - osobne uz po prevzeti a rozdeleni Hitachi nevim co na servery kupovat. V pripade tvrde havarie jsou moznosti recovery na ext4 omezene, ale v tomto smeru neni situace u ext4 horsi nez u FS podobne generace.

[Sten]

Doporučuju RAIDové disky, pokud teda nevadí o dost vyšší cena nebo nižší výkon. Dobré zkušenosti mám se Seagate ES a ES.2 a WD RE2 a RE4. Teď zkouším Redy a kromě dost mizerného výkonu jsou zatím spolehlivé, na pole s menším zatížením IMO dobrý kompromis mezi výkonem a cenou.

[little.owl]

Tak WD Red vypadaji prijatelne, zejmena kvuli trilete zaruce, i kdyz u WD mam pocit ze tady resi problemy, ktere si sami udelali (WD Green a jejich uparkovani se k smrti). Radsi bych neco s 1TB plotnami, tim ty starsi typy padaji. Na Hitachi jsem ocenoval jejich pomerne poctivou implementaci ATA standardu, budu mit k dispozici na test novou 3TB Toshibu, ktera je prevzala, pak uvidim.

[Aleš Kapica]

Ano. Já o voze, vy o koze. Podstatou sdělení je skutečnost, že fsck na ext systému opraví systém takovým způsobem, že poškozený git repozitář už nejde opravit.

Já ext systémy používám, ale používám i souborové systémy kterým věřím víc - kupř. Btrfs, které duplikuje metadata.

Moje zkušenost je totiž taková, že v současné době nelze na HW kvalitu spoléhat.

[little.owl]

fsck na ext systému opraví systém takovým způsobem, že poškozený git repozitář už nejde opravit.

kupř. Btrfs, které duplikuje metadata.

Pokud vam zacne selhavat HW a data proste nejsou na fyzickem zaznamovem mediu, tak vas nezachrani vubec nic. Faktem, ze btrfs vam v nekterych situacich muze pomoci, ale ani to neni panacea a hlavne to neni zatim v produkcnim stavu.

[Aleš Kapica]

..a hlavne to neni zatim v produkcnim stavu.

Nemůžu si pomoci, ale za tu dobu, co bez problémů "experimentální" Btrfs používám, se u ext4 objevilo už několik dosti fatálních chyb, které mohly vést ke ztrátě dat. A je dost dobře možné, že některá z nich byla i v pozadí problému s ext4 v mém případě.

[little.owl]

Take bych to videl podobne, problemy jsem mel jen jednou u virtualizace a to je problem IMHO jinde.

[Sten]

+1 Spouštět virtualizované servery s disky v souborech si koleduje o podobný průšvih, protože změněné bloky těch souborů mohou být zapisovány v jiném pořadí, zatímco ext* (a vlastně všechny žurnálové souborové systémy) spoléhá, že to bude FIFO, navíc pokud ty soubory budou třeba na XFS, tak při výpadku proudu můžete říct všem virtuálům pápá. Na druhou stranu pokud zapnete synchronní zápis těch souborů, tak tím hodně zlikvidujete výkon těch serverů. Proto taky KVM umí používat LVM a fyzické oddíly.

[little.owl]

Proto taky KVM umí používat LVM a fyzické oddíly.

+1 To je cesta.

[Aleš Kapica]

Žijte dál ve sladké iluzi.

[little.owl]

A kterou mate na mysli?

[Aleš Kapica]

Že se problém vyřeší pokud se virtualizuje přímo nad fyzickým zařízením.

Zaobírám se virtualizací už dost dlouho. Používal jsem a používám různé souborové systémy. Zkoušel jsem všechny možné varianty. Zajímavé je že do stavu totálního kolapsu se dostaly vždy pouze stroje, které používaly ext FS. Přes tyto špatné zkušenosti ale ext FS používám, protože ono je vždy něco za něco.

Dnes už ale preferuji bezdiskové řešení. NFS server sice má vypublikovaný diskový oddíl s ext4, ale ten je replikovaný přes DRBD. V dohledné době ho však plánuji změnit na Btrfs.

Virtuály co mám ve škole se navíc kompletně jednou denně zálohují na pole s Btrfs, kde se vždy udělá vůči každé záloze snapshot. Z té lze prakticky ihned kompletně obnovit kterýkoliv z virtuálů, aniž by to vyžadovalo víc než vyexportování záložního adresáře.

Data jsou na polích typu raid6, což minimalizuje právě pravděpodobnost narušení dat ze strany problémového hardware. Osobně si velmi slibuji od implementace raid6 do Btrfs. Už jsem to zkoušel, a vypadá to velmi slibně. V notebooku používám Btrfs v módu raid1. Svěřit data jedinému SSD disku bych si totiž opravdu netroufnul.

[Sten]

Tady nejde jen o ext*. I btrfs nebo XFS celkem snadno rozbijete tak, že se nedokáže opravit, pokud budete virtualizovat nad soubory. Při virtualizaci nad fyzickými zařízeními (včetně třeba iSCSI) se to nestane, pokud se nerozbije HW (potom vám už nepomůže nic).

RAID 6? Hmm, žijte si tu sladkou iluzi Ono totiž stačí, aby se zbláznil řadič disků, vyhodil víc než dva disky a data máte v pytli. MD RAID pak už nezjistí, odkud má obnovovat. (Osobní zkušenost: 12diskovému MD RAID poli vypadl jeden ze tří řadičů a zpátky jsem dostal tak 80 % dat, protože MD RAID to neustál a totálně rozbil i XFS pod tím.) btrfs RAID 6 sice slibuje lepší stabilitu, protože metadata jsou v RAID 1, ale stejně bych tomu moc nevěřil, dokud to nebude skutečně vyzkoušené. Ne nadarmo se na enterprise storage používá RAID 10.

[Aleš Kapica]

Pokud vím tak raid 10 není nic víc než dvě pole typu raid1 spojené do raid 0 ale možná se teď pletu. Každopádně každé řešení musí být vyváženo rozumnou strategii. Čím víc řadičů, tím víc kritických bodů. Proto dělat raid6 z více než 4 disků je pitomost. A použít nad ním XFS které je citlivé na výpadky napájení..

To řešení může být rychlé ale určitě ne bezpečné.

[little.owl]

Pokud vím tak raid 10 není nic víc než dvě pole typu raid1 spojené do raid 0

Ano, dve raid 1 (mirroring) spojene do raid 0 (stripping) - a stripe of mirrors.

[Sten]

Může jich být i víc než dva

[Aleš Kapica]

Může, ale pak je to neekonomické. I když tohle je samozřejmě relativní.

Dnes se prodávají desky co mají 8 sata portů celkem běžně. Osobní zkušenost - než kombinovat v poli disky navesene na různé řadiče, je lepší kombinace polí na samostatných radicich. Tedy než při aplikací tří čtyřportovych řadičů použít pole typu raid6 z 12 disků, je lepší udělat pole raid60, tj. 3x raid6 spojený do raid0. Ovšem pole seskladane tak, aby výpadek jednoho řadiče neohrozil data. Tj. Z jednoho řadiče max 2 disky v jednom raid6 poli.

[petr_p]

Tj. Z jednoho řadiče max 2 disky v jednom raid6 poli.

Aha, takže nejde ani tak o počet portů:

Dnes se prodávají desky co mají 8 sata portů celkem běžně.

Ale o počet řadičů. Ono totiž není problém mít všechny porty řízené jediným řadičem.

[Aleš Kapica]

To jsou dvě různé situace. Obvykle mají řadiče 2-4-8 portů.

Pokud mám řadič, který zvládne všechny disky bez omezení výkonu, je výhodné použít jen ten jeden. Kupř. já mám v hlavním datovém serveru dvě pole - jedno "visí" na portech řadiče co je na desce a druhé, na které se zálohuje, na přidaném čtyřportovém řadiči.

Doma mám desku s 7 porty. A další dva řadiče, každý se dvěma porty. Zkoušel jsem různé kombinace ale nejspolehlivější se nakonec ukázalo mít pole pokud možno na jednom řadiči. Takže mám 1xraid1 a 1xraid6 + blue-ray mechaniku a na přidané řadiče jsou napojeny pouze boxy.

Pokud bych však řešil situaci jako kolega o kus výše - tedy 3 řadiče (předpokládám že čtyřportové) a nad nimi jedno velké pole, tak bych to udělal tak jak jsem naznačil. I když ideální by bylo v takovém případě mít řadiče čtyři.

Každé raid6 pole by bylo 2+1+1. Pokud by kompletně chcípnul některý řadič, tak by sice jedno raid 6 pole bylo silně ohroženo, nicméně z hlediska dat by to nebyla žádná tragédie.

Z hlediska pevných disků by za příznivé konstelace takové pole typu raid60 ustálo i výpadek více než dvou disků.

I pole typu raid 10, lze vytvořit tak, že výpadek jednoho řadiče by neznamenal kolaps. Ovšem to by nesměl být žádný disk zrcadlený v rámci jednoho řadiče. Z hlediska pevných disků by znamenal ztrátu dat kolaps dvou vzájemně zrcadlených disků - ktežto u pole raid60 by byla data ohrožena až pokud by vypadnul z takového pole disk třetí.

[Sten]

Proč neekonomické? Když potřebujete zvýšit výkon stodiskového pole, tak je to naopak velmi ekonomické Samozřejmě na osmidiskových strojích se to asi moc používat nebude.

Btw. zrovna nedávno jsem řešil, kolik disků lze vlastně připojit do Linuxu. Dostal jsem se k tisícovce, pak mě to přestalo bavit.

[Aleš Kapica]

Bohužel takový hardware na hraní nemám. A nemá ho k dispozici ani nikdo koho znám.

[Sten]

Tak tisícidiskové stroje taky nemám k dispozici, zkoušel jsem to ve virtuálu, jen mě zajímaly reálné limity. U procesorů je limit na 4 096, u paměti 64 TiB RAM, ale u disků jsem žádné číslo nenašel.

[little.owl]

zkoušel jsem to ve virtuálu, jen mě zajímaly reálné limity.

[Aleš Kapica]

Prima. Tak jsme se zasmáli a můžeme přejít k těm skutečně reálným limitům a to je max. 36 ks 3.5" disků na jednu 4U jednotku. Nebo 24 ks 2.5" disků na 2U.

[Aleš Kapica]

I když jak tak koukám, dají se pořídit i 4U bedny na 45 ks 3.5" nebo 88 ks 2.5" disků.

[little.owl]

Mame v praci 2 kusy tohodle.

[Aleš Kapica]

Pěkné. Taky by se mi líbila možnost si takový stroj vyzkoušet. Ale pro nás by to byl zbytečně drahý luxus. Všechny tři stroje co používám ve škole stály dohromady zhruba polovinu toho co jedna taková krabice a stále bohatě stačí.

[Sten]

A co třeba tohle?

[petr_p]

Velikost block minor čísla?

[Sten]

Jakou výhodu má RAID 6 ze 4 disků oproti RAID 10 ze 4 disků? Teda kromě toho, že je to výrazně pomalejší

[Aleš Kapica]

Mohou vypadnout LIBOVOLNÉ dva disky. U raid10 pokud vypadnou zrovna disky co mají spolu raid1 jsou data na nich uložená v pytli.

[Heron]

v pytli

V záloze.

[Aleš Kapica]

V ideálním případě

[Heron]

No já bych řekl, že zálohování je základ. Lze diskutovat o tom, jak dobré to zálohování má být. Ale být prostě musí.

Jak tu někdo podotkl, doma si zálohuji pokud možno na dva různé externí disky - dva pro případ, že by něco chcíplo a vzalo s sebou všechny disku, i ten připojený zálohovací. Data (starší) jsou pořád na tom co je offline. Ano, není to na jiné geografické lokalitě, ale kdyby ten barák spadl jako ve Frenštátě, tak budu pěkně dlouho řešit úplně jiné problémy, než chybějící fotky.

[Aleš Kapica]

Samozřejmě že zálohování je základ. Narážka byla na samotný kořen této diskuze, kde očividně administrátoři nějakému zálohování moc nedali.

Pokud se s daty průběžně pracuje, je jich moc, a není dost financí na high-end řešení, není smysluplné zálohování reálné.

Proto jsem zvolil raději řešení, které mi v případě problému umožňuje zavčas podniknout kroky k tomu, aby ke ztrátě dat nedošlo. Dříve jsem měl totiž data roztroušená všude možně. Sice bezpečně uložená, akorát nedohledatelná. Teď je mám na jedné hromadě a čas od času - když mám náladu - je přebírám.

Na druhou stranu - dosáhnul jsem z hlediska uložených dat limitu, který se už moc nezvětšuje (cca 4TB). Data samozřejmě i nadále přibývají, ale tím že je postupně třídím a odstraňuji duplicitní data, která se za ty roky nahromadila, zůstává celkové množství dat zhruba stejné.

Je tedy už jen otázkou času a financí, kdy pořídím sadu disků s dostatečnou kapacitou a stávající řešení doplním o zálohovací mechanismus podobný jako používám u virtuálních strojů.

[Sten]

Na druhou stranu rekonstrukce RAID 10 je výrazně rychlejší, čímž se o dost snižuje riziko rozpadnutí pole.

[little.owl]

Že se problém vyřeší pokud se virtualizuje přímo nad fyzickým zařízením.

To jsem nerekl. Podporil jsem tvrzeni, ze neni dobre vitualizovat nad file systemem, ale je treba pouzit primo partition.

Data jsou na polích typu raid6, což minimalizuje právě pravděpodobnost narušení dat ze strany problémového hardware.

Raid 10.

[_]

a umi uz LVM pouzivat bariery?

[Pali]

Jeeejda. A ja sa mozem cudovat ze sa mi vcera nedarilo poriadne nic pushnut a nedokazal som vytvorit ani vlastny personal clone na kde serveri a pri tom som postupoval presne podla navodu na: https://community.kde.org/Sysadmin/GitKdeOrgManual#clone Skoda ze nezupdatovali tu wiki ze to z technickych pricin nejde...

Faktom ostava ze priklaz clone v gitolite stale nefunguje, takze nema cenu to ani skusat...

[Zadejte vaše jméno]

Tolko malo chybalo a mohol byt ten 4kovy balast prec :D

[pavlix]

To asi těžko.

[Jakub Lucký]

Autor vydal další vyjádření, kde více specifikuje jak to všechno bylo

[little.owl]

Porad stejne mlzi.

The second bug was thinking that git clone --mirror behaves the way that we expect it to behave based on the man page.

Co si tedy vlastne mysleli?

RAID/DRBD/Etc.

I don’t really need to go here. These are useful for keeping your server up and running, not preventing corruption.

...

[chrono]

O niečo ďalej sa píše, že mali použiť prepínač --no-local (oni použili --no-hardlinks) a v takom prípade by sa chybová hláška zobrazila. Pri --no-hardlinks ale nie je v manuáli uvedené, že to môže spôsobiť problémy (teda vlastne nie je uvedené, že ak sa klonuje lokálne, tak sa môžu obchádzať nejaké kontroly).

Každopádne problém je, že git clone môže vrátiť návratový kód 0, aj keď nastane nejaká chyba (to objavil už včera Jeff King a podrobnosti sú v jeho emaile v git mailing liste).

[little.owl]

Cetl jsem to pred jejich updatem:

UPDATE: in fact, it appears that the problem was our testing methodology after the fact, where we should have used –local but instead used –no-hardlinks; the man page is consistent. However, there are still failure states you can hit when using mirrors that will cause git clone to exit with a status code of zero.

Opet budu citovat manual:

--local

When the repository to clone from is on a local machine, this flag bypasses the normal "git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. If the repository is specified as a local path (e.g., /path/to/repo), this is the default, and --local is essentially a no-op. If the repository is specified as a URL, then this flag is ignored (and we never use the local optimizations). Specifying --no-local will override the default when /path/to/repo is given, using the regular git transport instead. To force copying instead of hardlinking (which may be desirable if you are trying to make a back-up of your repository), but still avoid the usual "git aware" transport mechanism, --no-hardlinks can be used.

--no-hardlinks

Optimize the cloning process from a repository on a local filesystem by copying files under .git/objects directory.

Takze jsme opet na zacatku.

git clone môže vrátiť návratový kód 0, aj keď nastane nejaká chyba

To je problem.

[chrono]

Vlastne ak sa pri lokálnom klonovaní povolia hardlinky, tak sa (logicky) nekontroluje nič. Ak sa hardlinky zakážu, tak sa súbory síce skopírujú, ale správnosť dát sa nekontroluje.

[little.owl]

ale správnosť dát sa nekontroluje.

Ale proc by pri lokalnim kopirovani mela? Ocekavate takovou kontrolu od cp? Git nikdy nedelal vic nez nutne minimum a nastroje pro kontrolu repository jsou.