Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Linus Torvalds nedoporučuje používat souborový systém ZFS na Linuxu. Do Linuxu jej nezačlení, dokud nedostane oficiální dopis od společnosti Oracle podepsaný jejich hlavním právním zástupcem nebo nejlépe samotným Larry Ellisonem, že jej začlenit může a výsledný kód může být GPL [Hacker News].
Tiskni
Sdílej:
Já to nedoporučuju už celou věčnost.
And as far as I can tell, it has no real maintenance behind it either any moreMyslim, ze to dostatocne ukazuje ze konkretne tento Linusov rant treba brat s velkym odstupom.
And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd.Neviem preco vobec zacal riesit to ci ten kod zacleni do jadra alebo nie, pretoze to nikto predtym neriesil a myslim ze kazdemu je jasne ze to sa nestane. (a pokial viem diskusia je len o tom ci s tym ma problem GPL, CCDL pokial viem pridanie dalsej licencie umoznuje pokial bude zachovana aj CCDL) cize Oracle s tym zrejme problem nema uz davno a ten podpisany papier by skor potreboval od FSF. Kazdopadne to bol rant dost mimo temu ktorou bol fakt, ze niekolko exportov prepli z EXPORT na EXPORT_GPL, cim rozbili (okrem ineho aj) ZFS. (uz je to fixed)
Verze ZFS, o které hovořil Linus, je svobodná, a nevím, proč má takové výhradyProtože dle většinového výkladu (významnější výjimkou je pouze Canonical - Ubuntu) je licence CDDL nekompatibilní s GPL a začlenění tudíž není možné z právních důvodů (a případné problémy by se pak přenesly na všechny uživatele Linuxu, protože by používali kód v rozporu s licencí.) Druhým problémem je, že si v některých ohledech si ZFS hraje na vlastním písečku, přičemž v linuxovém jádře dlouhodobě platí, že pokud má někdo lepší implementaci pro nějakou oblast, tak ji má do jádra dát jako obecnou funkcionalitu pro všechny, ne si ji sušit jen pro sebe. To je nicméně podružné a hlavním problémem je odstavec výše.
The benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it either any more, so from a long-term stability standpoint, why would you ever want to use it in the first place?To je uplne stejna liga jako bezna demagogie od trollu tady na Abicku
Ja bych radil lidem obracene - nepouzivat Linux. Jenze to se ve svete linych dockeristu dost blbe nekomu vysvetluje.Alternativy? Požaduji binární distribuci software a dostatečně aktuální vývoj, ne čekat třeba na podporu hardwarové virtualizace několik let jako to bylo u FreeBSD
V projektu neexistuji bezpecnostni chyby, bezpecnostni chyba je proste "chyba", kterou mozna nekdo nekdy opravi.Úmyslně dezinterpretujete...
Navrh featur, ktere Linux dostava, se podrizuje tomu, co se tihle chytri panove uraci prijmout, i kdyz se casto nabizi lepe promyslene alternativy a lepsi napady na dany pristupProtože snajpa ví víc, než desítky lidí, kteří se v oboru pohybují desítky let a mají trochu víc rozhledu, než je provozování vpsfree. Btw. jakpak jste vyřešili to, že sync() zavolaný z jedné virtuálky synchronizuje celý filesystém hostitele? Trefím se, když budu hádat, že patch v jádře je, že sync() teď nedělá nic?
A ten GPL fasismus je pak uz jenom tresnicka. CDDL je svobodna licence, at si strejda Linus mysli, co chce.Citujte strejdu Linuse, kde tvrdí, že CDDL svobodná není. Podstatné je, že je GPL nekompatibilní, tj. začlenění kódu by přineslo problémy.
Kdyz patch, co odstranuje hlidani GPL licenci, bude tez pod GPL licenci a cely vysledek bude ven pod GPL licenci (a nebude se jmenovat Linux), muzou mi tak akorat vycadit pr...Jste jak vzteklé děcko, respektovat práci a vůli jiných lidí je tak nějak základní slušnost.
kdybychom meli respektovat kazdeho do posledni tecky, co si kdy vymysli, uz by se to v te chvili ani v tech distribucich, co na to jdou takhle od lesa, nemohlo jmenovat Linux.Ale mohlo. Ono asi nikdo - a určitě ne autoři GPL kódu - nechce, aby si distribuce nemohly upravovat jádro dle svých potřeb. Ale někteří z těch, co píšou GPL kód, si přejí, aby ostatní buď přispívali stejným způsobem, nebo jejich kód nepoužívali, ale napsali si vlastní. Pak ovšem přijdou ukřičená děcka s tím, že mají nárok si cizí práci přivlastnit za svých vlastních podmínek. A ještě se plácají po zádech, jak to tím patchem krásně vyřešili.
Kdyste používali reiserfs, nemusíte řešit tyhle problémy s korporátníma sračkama.
Ruská prostitutka. Koupil si ji na eshopu.
Je to o tom, že Linux zatím nemá pro ZFS žádnou alternativu.Je to o tom, co si kdo představí pod pojmem storage a co od toho očekává a co je ochoten akceptovat. Na rootu včera vyšel první díl seriálu o btrfs a ačkoliv nevím, jak to bude vypadat dál, vidím v tom náznaky toho, jak se někteří lidé na storage obecně dívají. A je to pro mě trochu skličující. Uvádí tam, že BTRFS má raid. Ne BTRFS nemá raid, btrfs je multidevice fs a to je naprosto klíčové. Kdykoliv přidám disk, kdykoliv jej odeberu. To je to podstatné, ne to, jestli raid-1 znamená mirror přes dva disky nebo přes všechny. Podstatná je ta flexibilita. Stejně jako je podstatná flexibilita ve vytváření subvolume / snapshotů. To je zásadní rozdíl od starých FS typu ZFS, kde si opravdu nemůžu dropnout jakýkoliv dataset, který má clone nebo snapshot. O odebrání disku z některých typů vdevu ani nemluvě. Ta flexibilita umožňuje úplně jiné myšlení.
A pak tu máme věci jako problém s výměnou disku za běhu.Ten článek je skoro 5 let starý. A řešení tam naznačuji: "můžu mít disky v hw nebo software raidu1 a potom mít v btrfs raid0. Btrfs nikdy výpadek disku neuvidí." Pro mě tohle prostě není téma. A neslyšel jsem tolik nářků na neexistenci RAID-5/6 než s BTRFS. Nikdy před tím jsem neslyšel, že by lidé chtěli tak moc používat RAID-5 než až se dozvěděli, že btrfs raid-5 nezvládá. Najednou to každý strašně nutně potřeboval (a řešení mdadm raid-5 a nad tím btrfs nebylo nějak po chuti, zatímco totéž s ext3 bylo akceptovatelné). Totéž jako s IPv6. Hromada lidí mluví o 128b jako nedostatečném a dělení na 2x64b je nesmysl a raději zůstanou u IPv4 (32b), než někdo nevymyslí něco lepšího. Pro mě je jediné storage řešení na úrovni RAID-10. V případě btrfs multidevice raid-1. Paritní raidy mě nezajímají. Totéž u ZFS, přidávat další mirror vdevy.
nebo můžeme začít věřit ve Stratis, kde se Redhat snaží doboostit XFSNejen XFS. Ale i dm a md. Nemám nic proti tomu projektu, ale mám hodně proti tomu se tvářit, že to jsou oddělené vrstvy u kterých je "jenom potřeba doplnit trochu víc obousměrné komunikace". Takže to vlastně už nejsou vrstvy ale monolit. Osobně si myslím, že správná cesta je se na toto vykašlat, disky brát jen jako storage pro bloky (4k, 1M. 1G, cokoliv se hodí) a nad těmito bloky vytvořit pool (podobně jako LVM VG) a až nad ním tvořit volitelnou redundanci. Něco jsem popsal v tomto textu.
a přejít na něco cloudového, něco jako CephCEPH má defaultní redundanci 3 kopie a najednou raid-5 nebo 6 nechybí? Jinak CEPH je daleko náročnější projekt, než si kde kdo myslí. Nám se to podařilo na počkání kdykoliv shodit. Je možné, že se něco změnilo, rok a půl jsem to neviděl, ale před tím se nám podařilo zlikvidovat cephfs i rados block device (object api jsme nezkoušeli, to tehdy nebylo na pořadu). Někdo (trekker.dk) tvrdil, že qemu driver je OK, to jsme netestovali. Ten projekt podle mě není dobře vedený, viz jen historie backendů: měli vlastní storage, potom doporučovali ext, btrfs, xfs a opět vlastní storage. Takhle se s daty nezachází. Podobné projekty obvykle používají něco naprosto primitivního (ext2) a v případě problémů to rovnou zahodí a zreplikují znovu. Jestli se "storage cloud jánevímco" neumí za 14 let ani rozhodnout na backendu, tak je něco špatně. Nefunguje ani frontend (dva ze tří).
CEPH má defaultní redundanci 3 kopie a najednou raid-5 nebo 6 nechybí?Ale no tak, takovýhle logický klam je přece jenom trochu moc průhledný... defaultní redundance neznamená, že chybí raid-5.
viz jen historie backendů: měli vlastní storage, potom doporučovali ext, btrfs, xfs a opět vlastní storage. Takhle se s daty nezachází.Mhm... já bych teda řekl, že s daty se zachází tak, aby nebyla ztracena, nemají-li být. Historie backendů na tomto nic nezměnila, migrace je samozřejmě možná za běhu...
defaultní redundance neznamená, že chybí raid-5On CEPH nabízí nějaké partitní raidy? Klidně se nechám poučit, co jsem to viděl naposledy, tak uměl jen celé kopie dat.
migrace je samozřejmě možná za běhuNo to možné je, ale to nemění nic na mém subjektivním názoru, že projekt (libovolný) jehož podstatná část se mění příliš často, není příliš dobře veden. To nesvědčí o dobré analýze problematiky a pokud se to stane po x-té, tak by to mělo někoho trknout a měl by se zrevidovat postup výběru dané technologie. Já prostě mám rád dlouhodobě stabilní projekty, kde někdo na počátku dlouho přemýšlel a není nutné podstatné komponenty radikálním způsobem měnit. Někdo to může mít jinak, CEPH umožňuje měnit typy OSD za běhu, takže to pro někoho nemusí být takový problém.
On CEPH nabízí nějaké partitní raidy?Paritní raidy ne, místo toho je tam erasure-coded pool, tj. kombinace k stripů a m opravných kódů, kde k a m volí uživatel. Je to tam od roku 2014 (pro RBD a CephFS od 2017.)
Já prostě mám rád dlouhodobě stabilní projekty, kde někdo na počátku dlouho přemýšlel a není nutné podstatné komponenty radikálním způsobem měnit.Na druhou stranu není špatné, když projekt může něco, co se nehodí pro daný účel, vyhodit, protože to nefunguje a dá se to udělat lépe. Krom toho se nejednalo o žádné radikální změny, to byla až ta poslední, kdy skutečně použili vlastní storage. To předtím bylo bylo jenom hledání optimálního filesystému, princip ukládání dat se neměnil. Akorát se ukázalo, že žádný takový fs není. (Hádám, že potřebovali ušetřit na vývoji a až po letech měli dost velké příjmy na to vytvořit si vlastní storage.)
Na druhou stranu není špatné, když projekt může něco, co se nehodí pro daný účel, vyhodit, protože to nefunguje a dá se to udělat lépe.Tak to každopádně.
To předtím bylo bylo jenom hledání optimálního filesystémuZa 10 let 5 FS. Na počátku vlastní FS (EBOFS), potom btrfs (2008 - to byl snad rok na světě?), někde s tím ext3, potom xfs (2012) a potom vlastní BluStore. Nedohledal jsem, jak dlouho na tom pracovali, ale tak něco kolem 4 let max a v 2017 už je to default OSD (ano, lze použít i XFS). Ale tak jistě, udělat object storage + mini fs pro embedded db (RocksDB) je určitě trivka, to se dá za 4 roky zvládnout.
vlastní storageCož ve mě vzbuzuje ještě méně důvěry. Udělat robustní FS trvá prostě dlouho, XFS je tu s námi od roku 1994. Nepřijde mi moc rozumné si myslet, že dovedou vyrobit interní FS pro RocksDB (takže fs s naprostým minimem uživatelů, zatímco ostatní FS dostávají nakládačku v běžném provozu, tak tady ne) a k tomu ještě block storage (ok, ten je jednoduchej). Ale tohle je prostě přístup toho projektu no, kdo to akceptuje, ať to používá, zase je potřeba říct, že jsou v tomhle konzistentní. Nejdřív si spíchnou vlastní FS, potom použijí novorozeně btrfs (necelý rok staré), potom určitě po dávce patchů od RH v roce 2012 doporučí XFS (takže vlastně taky dost mladej fs) a potom opět hurá na vlastní storage. Každopádně je zajímavé to sledovat
The erasure-coded pool crush ruleset targets hardware designed for cold storage with high latency and slow access time. Takže v podstatě pro archivy, které se moc nebudou číst ani měnit. OK.No jo, počítat kontrolní součty při zápisu a tahat data ze všech disků při čtení je pomalejší než pracovat s čistými kopiemi... to bych považoval za vlastnost, stejně jako u raid 5 a 6. (Kromě hardwarových řadičů, kde je to občas vylepšené tím, že to počítá dedikovaný čip.)
Za 10 let 5 FS. Na počátku...Udělat robustní filesystém určitě není trivialita, ale o filesystém se v podstatě nepokouší, protože většina funkcionality běžných filesystémů tady není potřeba. Proto taky ustoupili od ukládání dat na filesystémy, mělo to zbytečně velkou režii za věci, které duplikovaly to, co ceph dělal sám.
Ale tohle je prostě přístup toho projektu no, kdo to akceptuje, ať to používáPár let, kdy se v podstatě na odpadní hardware, který už k ničemu nebyl, denně odleje 600GB záloh - zatím bez problémů.
Pár let, kdy se v podstatě na odpadní hardware, který už k ničemu nebyl, denně odleje 600GB záloh - zatím bez problémů.Jasně, to je asi ok. U nás jsme se pokoušeli to nasadit jako produkční storage pro vmware a tam bylo špatně vlastně úplně všechno. (Už jsme se tu o tom hádali.) BlockDevice (připojení přes iSCSI) padal, CephFS export přes NFS padal, dokonce jsme zkoušeli připojit CephFS do jednotlivých VM, to taky padalo. Tím jsme vyčerpali všechny možnosti. Cílem bylo mít storage pro vmdk pro vmka, ideálně tedy blockdevice a isci, v nejhorším na nfs (tak jak nám to běželo roky před tím na ext4 + nfs export do vmware), takže už nebylo co dál testovat. Osobně si myslím, že nejlepší použití je pro S3 API object storage, ale to se pro naše nasazení nehodilo. Ty to láduješ na ten CephFS? Jak to máš připojené, do všech zálohovaných strojů, nebo naopak ty data sypeš na jeden ceph node?
U nás jsme se pokoušeli to nasadit jako produkční storage pro vmware a tam bylo špatně vlastně úplně všechno...Jo, o RBD ovladači v kernelu pár let zpátky mluvil někdo na Linuxdays (asi), že je naprosto k h-u. O CephFS nevím nic, ale hádám, že jaderný ovladač na tom bude úplně podobně. Tipuju, že vývojáři Cephu na přispívání do jádra kašlou, protože je to náročnější a/nebo to není jejich hlavní use-case - např. RBD ovladač v jádře 4.19 z Debianu Buster nepodporuje věci, které Ceph umí už léta. Jinak přidali vlastní iSCSI bránu https://docs.ceph.com/docs/master/rbd/iscsi-overview/ , ale nezkoušel jsem, na Stretchi byl moc starý user space.
Ty to láduješ na ten CephFS? Jak to máš připojené, do všech zálohovaných strojů, nebo naopak ty data sypeš na jeden ceph node?Jedna Qemu virtuálka, 10 RBD zařízení, každé připojené zvlášť přes userspace knihovnu (driver=rbd), v tom virtuálu jsou to pak všechno scsi-disk pověšené na virtio-scsi. Nic pro VMWare, ještě by lidi mohli chtít neplatit za jejich software-defined storage a místo toho používat tohle.
Jedna Qemu virtuálka, 10 RBD zařízení, každé připojené zvlášť přes userspace knihovnu (driver=rbd), v tom virtuálu jsou to pak všechno scsi-disk pověšené na virtio-scsi.To je teda zvláštní řešení pro zálohy. Proč do virtuálky? Proč 10 blockdevice? Co potom s tím v té virtuálce, to spojíš (LVM?) a nad tím nějaký normální FS? Já teda pro zálohy volím co nejjednodušší řešení, většinou jen hw raid, co nejstandardnější fs (xfs) a je to. Zálohované stroje at si připojí svůj nfs chlívek, nebo tam ta data pošlou jinak (backuppc), na zálohy vmware nakivo. V některých variantách se k tomu připojí i pásková knihovna, data má rovnou na místním disku, takže no problemo.
Zálohované stroje at si připojí svůj nfs chlívekTohle se mi nelíbí kvůli tomu, že když je zálohovaný stroj nějakým způsobem napaden, může útočník smazat (nebo v horším případě jen tiše poškodit) i tu zálohu. Pokud to dále odlévám na pásky, tak to až tak nevadí. Jiné řešení je na tom zálohovacím stroji dělat snapshoty, ale to na XFS (+LVM) ve větším moc efektivně nejde. Zálohovací storage se často využívá i jako archiv, ze kterého musí být snadné obnovit určité soubory nebo nějakou část FS k určitému datu. K tomu jsou ideální právě snapshoty, a to je pro mě důvod proč použít ZFS nebo Btrfs. Pokud snapshoty na úrovni storage nemám, používám rsync iniciovaný ze zálohovacího systému, který má na zálohovaný systém přístup přes SSH s možností spustit jen rsync sender v read-only režimu. Plus link-dest pro držení historie, ale to funguje jen po celých souborech. Home a mail storage pro pár stovek uživatelů má pár TB a desítky milionů souborů. Tam už je rsync dost na hraně, aby se vůbec stihnul z LVM snapshotu přes noc. Pro takové situace je send/receive ze ZFS neocenitelný. Na Btrfs už to možná spolehlivě funguje taky?
Tohle se mi nelíbí kvůli tomu, že když je zálohovaný stroj nějakým způsobem napaden, může útočník smazat (nebo v horším případě jen tiše poškodit) i tu zálohu. Pokud to dále odlévám na pásky, tak to až tak nevadí.Ano, odlévá se to, přesouvá mimo dosah NFS apod.
Zálohovací storage se často využívá i jako archivTohle se zase nelíbí mě. Archiv a záloha jsou kompletně jiné úlohy. Na archiv má být vyhrazený stroj / pásková knihovna. Z archivu by nemělo být potřeba vyzobávat jednotlivé soubory.
Na Btrfs už to možná spolehlivě funguje taky?Co send / receive? To mi fungovalo vždy (tedy minimálně od roku 2013). Ale na zálohy to nepoužívám, používám to na přesun kontejnerů mezi stroji. Zálohy btrfs snapshotů, pokud chci zachovat jejich historii, tak používám SquashFS. Pozor, poslední verze z roku 2019 obsahuje bug, který poškodí výsledný soubor a není možné appendovat. Dá se tomu zabránit volbou
-no-xattrs
. Předchozí verze 4.3 z roku 2014 je OK.
Na archiv má být vyhrazený stroj / pásková knihovna.Pokud nechci řešit pásky, tak to znamená jeden systém na backup + další systém na archivy. Oba s velikostí storage srovnatelnou nebo násobnou než velikost provozních dat. To mi přijde zbytečně nákladné. Většinou to řeším v podstatě archivním úložištěm se snapshoty zhruba 10-30 dnů zpět a 24 měsíců zpět. Nebo něco mezi tím. Z online archivů se pak dělají offline zálohy postupně na několik externích HDD, které se po dokončení kopírování odpojují a odnáší fyzicky jinam.
Z archivu by nemělo být potřeba vyzobávat jednotlivé soubory.A k čemu jinému by měl být? V našem use-case je vytažení jednotlivých souborů 90% případů využití archivu. Jedná se o home storage a maily - omylem smazaný nebo poškozený soubor/mail, který "tam určitě byl někdy před měsícem"; rozdrbaný Windows roaming profile, který uživatel ohlásí po týdnu; nebo pár archaických aplikací, která drží data v souborech a občas někdo potřebuje zreprodukovat stav jak byl před dvěma měsíci. Přes Sambu je možné takové snapshoty zpřístupnit i přímo uživatelům, a někteří se s tím i naučili dělat a používají to poměrně často.
cat /dev/sda > soubor
) se hodí všude tam, kde budu chtít obnovit stroj do zcela stejného stavu (typicky windows stroje, ntb se mi fakt nechce přeinstalovávat), takže mám několik image, tři měsíce dozadu.
Potom je to záloha a zálohu dělám do jiného FS, než je původní. Proto i ten BTRFS dávám do squashfs, nebo se to kopíruje na xfs apod. (Totéž ZFS.) Tak nejde o dokonalou kopii, ale o data a je to spíš pro případ náhodného smazání nějakého souboru uživatelem.
No a archiv je k uložení stavu projektu většinou po jeho dokončení. Aby se o to nepřišlo. To není určeno k okamžité obnově do produkčního stavu (taky to jde), ale o zachování dat a souvislostí mezi nimi. Takže do archivu jde repositář (svn / git), snímek develu, snímek produkce, dokumentace, tickety apod. jako ucelená kolekce patřící k sobě.
Jinak dělal jsem tohle mezi BTRFS (zdroj), ZFS (cíl) a úplně na férovku, ZFS to nezvládá. Zatímco na BTRFS jsem míval i desetitisíce snapshotů uložených na disku, tak tohle pro tři stroje nevydrželo ani rok (tj 3x365). ZFS nemá rádo mnoho snapshotů, potvrdil jsem si to loni během psaní této minisérie, ještě k tomu mám pár poznámek.
Prostě na stejném stroji, kde jsem měl před tím linux a btrfs a desítky tisíc snapshotů je teď ZFS (ve skutečnosti s rychlejšími disky) a ZFS nemá rádo velké množství snapshotů a projevuje se to třeba už jen na directory listingu, kdy vypsat strom o nějakých 400tis souborech trvá klidně i 3 minuty. Když se mu to uklidí, tak po nějaké době se to vrátí do normálu a je to opět během pár s.
$ time find . | wc -l 389469 real 0m1.835sLoni jsem si to potvrdil asi 3x po sobě a od té doby ZFS snapshoty používám jen na nezbytně dlouhou dobu.
Já teda pro zálohy volím co nejjednodušší řešení, většinou jen hw raid, co nejstandardnější fs (xfs) a je tocož mi nejde dohromady s tím blogem, kde zmiňuješ Btrfs snapshoty. Ale jasně, zaleží na tom, kolik těch dat je a jak se mění. Pokud ne moc, je standardní XFS + třeba rsnapshot dobrá volba.
Ale jak u těch záloh (např. na XFS) řešíš více verzí?To zálohovací pole je jen storage pro jiný software. Takže se to řeší v něm. Nakivo pro vmware, backuppc pro pecka, verze si to řeší samo (a btw, backuppc verze 4 už konečně nepoužívá hardlinky, fs to používá jen pro unikátní soubory a zbytek si to řeší v nějakém interní db - takže už to není tak náročné na iopsy a zejména počítání počtu linků, což klidně běželo 24h).
Ale jasně, zaleží na tom, kolik těch dat je a jak se mění.Spíš to záleží na tom s kým to děláš. A pokud máš lidi, kteří sotva chápou LVM, tak dělat cokoliv na BTRFS nebo ZFS a celé si to odnést na vlastních zádech, to se mi fakt nechce. Takže ve firmě se snažím všechno dělat as simple as possible a potom se vyřádím v soukromí. A ten blog je o tom soukromém řádění. Pochopitelně soukromě využívám btrfs mutlidevice a zfs apod, tak jak to popisuju na tom webu. Ale v práci to opravdu nebudu protláčet "proti všem". Ale to nemá být kritika, když vidím, jak se dodnes píšou články o storage z pohledu z roku 1980, tak se těm lidem ani nedivím. Pokud se o to někdo nezajímá, tak má dost zkreslenou představu o tom, co všechno je možné dneska dělat. Pro mě bylo multidevice fs + nezávislé snapshoty jako zjevení a okamžitě jsem věděl, co s tím chci dělat a pro ostatní je to vlastně nezajímavé.
Zálohy btrfs snapshotů, pokud chci zachovat jejich historii, tak používám SquashFS.Zajímavé, ale na několik TB a desítky milionů souborů mi to nepřijde moc vhodné. Jak jsem psal, potřebuji kvůli výkonu ideálně využit tu informaci z CoW vrtsvy FS. Xattrs (a ACL) potřebuji zalohovat taky, hlavně kvůli Sambě. Druhý popsaný způsob se send/receive je fajn, je dobré slyšet že to funguje. Já se o to zajímal kolem 2015, a to jsem narážel na info, že to nemusí být 100% spolehlivé, ale detaily už si nepamatuju. No a právě uvedená nevýhoda, že se k obsahu dumpu nelze dostat jinak než plným obnovením, je pro můj use-case skutečně velká a nepřekonatelná. Můžu ty data možná rozsekat na menší svazky a dělat jejich dumpy samostatně, ale někdy je i ten nejmenší smysluplný blok dost velký, a postup při obnovení série snapshotů složitý na to abych vytáhl pár souborů. Musel bych si k tomu alespoň generovat nějaký katalog co se kde a kdy změnilo -- umí třeba Btrfs vylistovat soubory, které jsou v daném snapshotu změněné od předchozího?
No a právě uvedená nevýhoda, že se k obsahu dumpu nelze dostat jinak než plným obnovením, je pro můj use-case skutečně velká a nepřekonatelná.Ale tak to je obecná vlastnost podobných sendů ne? Nebo ZFS lze obnovit jinak než na ZFS?
umí třeba Btrfs vylistovat soubory, které jsou v daném snapshotu změněné od předchozího?Ano:
btrfs subvolume find-new subvolume last_gen List the recently modified files in a subvolume, after last_gen ID.Je potřeba si to lehce vyfiltrovat, protože to ukazuje na každou změnu v souboru (takže soubor je tam několikrát):
inode 67479 file offset 1302528 len 32768 disk start 8972292096 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal inode 67479 file offset 1339392 len 4096 disk start 8972324864 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal inode 67479 file offset 1351680 len 12288 disk start 8972328960 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal inode 67479 file offset 1372160 len 32768 disk start 8972341248 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal inode 67479 file offset 1413120 len 40960 disk start 8972374016 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal inode 67479 file offset 1458176 len 57344 disk start 8972414976 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal inode 67515 file offset 0 len 90 disk start 0 offset 0 gen 25724 flags INLINE var/lib/postgresql/9.6/main/postmaster.pid inode 67516 file offset 0 len 8192 disk start 8972480512 offset 0 gen 25724 flags NONE var/lib/postgresql/9.6/main/pg_notify/0000 inode 67517 file offset 0 len 20480 disk start 8972500992 offset 0 gen 25724 flags NONE var/lib/postgresql/9.6/main/global/pg_internal.init inode 67518 file offset 0 len 114688 disk start 8972521472 offset 0 gen 25724 flags NONE var/lib/postgresql/9.6/main/base/13031/pg_internal.init inode 67519 file offset 0 len 28672 disk start 8971657216 offset 0 gen 25724 flags NONE var/lib/exim4/config.autogenerated
Ale tak to je obecná vlastnost podobných sendů ne? Nebo ZFS lze obnovit jinak než na ZFS?Nevím o tom, ale o to nejde. Jde o to, jestli ty snapshoty nakonec dlouhodobě skladuju na jiném FS (třeba XFS) jako soubory, nebo jestli je rovnou aplikuju na živý filesystem stejného typu na jiném stroji. Nějak jsem si to spojil s tím, že doporučuješ zálohovat na jiný typ FS, s címž bych souhlasil, ale má to pak tuto nevýhodu.
Je potřeba si to lehce vyfiltrovat, protože to ukazuje na každou změnu v souboru (takže soubor je tam několikrát)Díky, může se hodit.
Proč do virtuálky?Protože do ní jde připojit RBD
Proč 10 blockdevice?10 oddělených filesystémů. ext4 jsem ještě neopravitelně rozbité nezažil, ale opravitelně už jo - IIRC něco jako 2 TB maildirů a nešlo se dostat do jednoho adresáře, ve kterém vlastně ani nebyla žádná data, ale i tak se samozřejmě musel dělat fsck celého toho FS, což je paráda.. Fsck na 60TB filesystému bych dělal nerad.
Protože do ní jde připojit RBDSte masochisti. Tohle já třeba nedělám celkem ze zásady, pokud to nejde připojit normálně, tj buď jako systémovej blockdevice nebo jako normální fs tak s tím končím. I kdyby RBD ve qemu fungovalo bezvadně, tak mi opravdu nepřijde normální svěřit data něčemu, k čemu vede cesta jen klíčovou dírkou. (Ještě že to nevidí Kapica, ten by považoval za normální z té virtuálky exportovat nbd a připojit to jako blockdevice na hostiteli.)
10 oddělených filesystémů. ext4 jsem ještě neopravitelně rozbité nezažil, ale opravitelně už jo - IIRC něco jako 2 TB maildirů a nešlo se dostat do jednoho adresáře, ve kterém vlastně ani nebyla žádná data, ale i tak se samozřejmě musel dělat fsck celého toho FS, což je paráda.. Fsck na 60TB filesystému bych dělal nerad.To dává smysl. Já naposledy viděl ext4 na kolenou, když se trochu rozbilo promazávání session souborů a v jednom adresáři bylo 12milionů souborů. Mazalo se to 14 dnů. Od té doby ten fs psal directory index full, ale jinak fungoval.
(Ještě že to nevidí Kapica, ten by považoval za normální z té virtuálky exportovat nbd a připojit to jako blockdevice na hostiteli.)Na niečo podobného bola vyvinutá napríklad OpenDedup Appliance. Jedná sa o Virtuálne NAS ktoré má v sebe deduplikáciu a optimalizáciu na hosťovanie VMFS cez VMWare storage api. Ď za pripomenutie, hral som sa s tým pred rokmi. Ale performance mi nedovolila. Rád si to pozriem teraz keď mám na to vyčlenený SSD a dostatok RAM, i keď to TLC s maličkou SLC Cache ...
Tohle já třeba nedělám celkem ze zásady, pokud to nejde připojit normálně, tj buď jako systémovej blockdevice nebo jako normální fs tak s tím končím.A povězte mi, Kefalín, čo si predstavujete pod slovem "normálně"? Zrovna pro virtualizaci je blokové zařízení zbytečné, protože je to jen mezikrok, kde kernel emuluje blokové zařízení, aby následně komunikoval se síťovou službou, což může aplikace udělat sama. Navíc virtualizace je téměř určitě víc normální využití RBD než připojení do jednoho fyzického stroje. Pak není divné, že je víc usilí věnováno tomu, aby fungovala virtualizace. (Kde virtualizace samozřejmě znamená Qemu, protože to je také projekt Red Hatu.)
A povězte mi, Kefalín, čo si predstavujete pod slovem "normálně"?Třeba to, že to bude součástí kernelu, kernel modul a nebude se muset řešit to, zda to běží ve virtuálce nebo na HW. Prostě kdekoliv mám standardní kernel, tak to připojím.
Zrovna pro virtualizaci je blokové zařízení zbytečnéTo si právě nemyslím. KVM virtuálky vytvářím vždy nad LV a té virtuálce může být úplně jedno, jaké jsou pod tím PV. Buď to mám na klasických diskách, nebo ssd, nvme, nbd, drbd, iscsi, ale ta virtuálka o tom ani neví a žije si nad tím svým LV. A nemusí o tom vědět ani ta virtualizační technologie, prostě to má jako blockdevice a je to.
Třeba to, že to bude součástí kernelu, kernel modul a nebude se muset řešit to, zda to běží ve virtuálce nebo na HW.Takový přístup je ovšem iracionální. Představte si situaci, kde hledáte storage pro VMWare a dostanete nabídku na (hypotetické) VMStorage, které parametry předčí všechny ostatní nabídky, ale disky nelze připojit jinak, než jako disky virtuálek, protože se VMWare s ovladačem do jádra hostitele neobtěžoval. Na základě toho tuhle nabídku vyloučíte, přestože pro požadovaný účel (hledáte storage pro VMWare) je nejlepší.
To si právě nemyslím. KVM virtuálky vytvářím vždy nad LV a té virtuálce může být úplně jedno, jaké jsou pod tím PV. ... A nemusí o tom vědět ani ta virtualizační technologie, prostě to má jako blockdevice a je to.Dobře, nevýhody takového přístupu jsou jasné, u emulovaných blokových zařízení (rbd, nbd, iscsi) máte režii navíc, pro RBD i režii v device mapperu, který duplikuje něco, co Ceph dělá taky. (U RBD bych se navíc bál, že si tam vyrobíte bottleneck, protože jádro nebude ochotné dostatečně využívat toho, že to "zařízení" dokáže pojmout velký počet paralelních požadavků - přece jenom to standardní bloková zařízení neumí.) A pokud náhodou hypervizor umí pro konkrétní typ úložiště nějaké optimalizace, tak je vypnete. Jaký to má přínos?
Takový přístup je ovšem iracionální. Představte si situaci, kde hledáte storage pro VMWare a dostanete nabídku na (hypotetické) VMStorage, které parametry předčí všechny ostatní nabídky, ale disky nelze připojit jinak, než jako disky virtuálek, protože se VMWare s ovladačem do jádra hostitele neobtěžoval. Na základě toho tuhle nabídku vyloučíte, přestože pro požadovaný účel (hledáte storage pro VMWare) je nejlepší.To je úplně mimo, protože vmware si neinstaluju nad běžným linuxem, ale dostanu hotový produkt, který nainstaluju na HW. Je to blackbox, takže je celkem jedno, jak si to interně řeší. Já bych se především ze všech sil snažil vyhnout vmware samotnému a až potom bych řešil, zda ten který storage je lepší nebo horší. Preferuju obecná řešení, takže aktuálně máme storage přes SAS + iscsi a o speciální storage mountovaný do virtuálek nemám ani zájem ani kdyby existoval.
A pokud náhodou hypervizor umí pro konkrétní typ úložiště nějaké optimalizace, tak je vypnete.Ano, to se může stát. Ale není to vždy špatně. Na těch miskách vah je toho víc, než jenom "výkon" a některé jiné věci mohou převážit. Pokud bych se například k vůli tomu měl zbavit nějaké modularity a dostatečného oddělení a obecnosti daného řešení, tak bych si takové řešení nezvolil. I za cenu nákupu více HW pro "méně" výkonné řešení. Nehledě na to, že jsem za svůj život zažil už tolik zázračně výkonných řešení, že bych o tom mohl napsat knihu. Zázračné nejsou, nakonec to totiž vždy záleží jen a pouze na hrubém výkonu HW, který je k disposici. A viděl jsem několik případů, kdy si někdo pro jednu zázračnou technologii zabouchl dveře pro jiná obecná řešení a nakonec neměl ani výkon, ani modularitu.
A najednou mi tady argumentujete specifickým ovladačem jen pro jednu věc na místo obecného v kernelu.Rozdíl je v tom, že u toho Qemu to není specifický vs. obecný ovladač, ale dva specifické ovladače - jeden pro soubor, druhý pro iSCSI (třetí atd. pro RBD, NBD, NFS, gluster...) A v tom kernelu to také není obecný ovladač, je to jen emulátor (který dost možná používá stejného RBD klienta - nebo přinejmenším kdysi postaveného na stejném základě - akorát v kernel space.)
To je úplně mimo, protože vmware si neinstaluju nad běžným linuxem, ale dostanu hotový produkt, který nainstaluju na HW. Je to blackbox, takže je celkem jedno, jak si to interně řeší.Pokud vím, tak ten VMWare používáte, takže ten příklad je relevantní. Pokud vám vadí closed-source, tak si místo toho můžete představit virtualizaci pomocí Qemu a hypotetické open-source úložiště HypoCeph, které je všemi parametry lepší než jiné nabídky, ale nemá ovladač na připojení disku do hostitele, jen do hosta. I tady je iracionální jej z výběru vyřadit.
Ale není to vždy špatně. Na těch miskách vah je toho víc, než jenom "výkon" a některé jiné věci mohou převážit. ....A konkrétně? Myslím konkrétně jaký přínos má ze všeho udělat blokové zařízení místo (například) připojit Qemu k iSCSI (RBD,...) přímo.
které je všemi parametry lepší než jiné nabídky, ale nemá ovladač na připojení disku do hostitele, jen do hostaZáleží na bodovém ohodnocení jednotlivých nabízených položek. Pro někoho může mít výkon váhu 15%, ale možnost obecného připojení třeba 60%. A třeba jiné položky mohou mít právo veta, třeba nesvobodná licence takového kandidáta může vyřadit rovnou a není potřeba se jím dál zbytečně zabývat. Pro mě je v tomto konkrétním případě (CEPH) klíčová dostupnost CephFS a v druhé řadě i RBD v kernelu, obé jsme vyzkoušeli, obé jsme shodili, není co dál řešit. Někdo jiný může být happy s tím, že si nad librados napíše vlastní objekt storage (tuším Německá pošta) a někdo je happy s tím, když mu to funguje v qemu. Není na tom nic i/racionálního, prostě každý to má pro svůj projekt vyfiltrované jinak.
Myslím konkrétně jaký přínos má ze všeho udělat blokové zařízení místo (například) připojit Qemu k iSCSI (RBD,...) přímo.No protože potom ta virtualizace nemusí mít speciální podporu pro x specifických ovladačů, může mít jen podporu pro blockdevice a tedy být jednodušší. A mít to všechno v kernelu je potom výhodné z toho důvodu, že to nemusím použít jenom ve virtualizaci, ale taky v čemkoliv jiném. Takže ta virtualizace o nic nepřijde a současně bude jednodušší a "konzumovat" výhody těchto specifických driverů může potom kterýkoliv jiný program, ne jen virtualizace. Přijde mi poměrně zvláštní, že tohle musím vysvětlovat. Vždyť toto je klasickej unixovej princip. Proč by si měl každej program psát svůj specifický driver pro něco, když stačí obecné rozhraní (soubor, blokové zařízení) a o export toho zařízení se pro všechny postará někdo jinej. A potom úplně cokoliv, co umí pracovat se souborem, se k tomu může připojit.
Záleží na bodovém ohodnocení jednotlivých nabízených položek.Pokud dáváte možnosti obecného připojení vysokou váhu v případě, že obecné připojení není a nebude způsob, jakým se daná technologie bude při nasazení používat, je to špatně/iracionálně nastavená váha
A mít to všechno v kernelu je potom výhodné z toho důvodu, že to nemusím použít jenom ve virtualizaci, ale taky v čemkoliv jiném.Takže přínosem je mít možnost, i když se ta možnost možná nevyužije... dobře, přiznám se, že jsem čekal něco hmatatelnějšího...
Přijde mi poměrně zvláštní, že tohle musím vysvětlovat. Vždyť toto je klasickej unixovej princip. Proč by si měl každej program psát svůj specifický driver pro něco, když stačí obecné rozhraní (soubor, blokové zařízení) a o export toho zařízení se pro všechny postará někdo jinej.Stejný argument ale můžete použít třeba pro webový prohlížeč - proč by si měl psát svůj specifický driver pro HTTP, když stačí obecné rozhraní, které v jádře všechno zařídí a výsledek bude v blokovém zařízení. Mně to fakt nedává smysl, aby program v user space schopný komunikovat se síťovou službou přímo používal jádro jako zprostředkovatele. Nemůže to mít lepší výkon a ještě je to hromada kódu, který běží s oprávněním kernel space.
že obecné připojení není a nebude způsob, jakým se daná technologie bude při nasazení používatNo ale cílem přece není používat nějakou konkrétní technologii. Resp ano, znám lidi, kteří objeví nějakou úžasnou (pro ně) technologii a potom se pokouší ji nějak za každou cenu použít. Já to dělám přesně naopak, já si nakreslím co chci dosáhnout, stanovím si podmínky a až potom na to hledám technologie. Spousta z nich vypadne a z toho zbytku se to postaví. (Pochopitelně už v procesu návrhu znám dostupné technologie a rád si udržuju big picture co je možné a co není, ale fakt to nestavím od těch technologií, ale od toho návrhu.) Což mimochodem kromě jiného umožňuje ty technologie snadno nahrazovat. Pokud nevyhovuje mdadm, nasadím tam hw raid a udělám pvmove. Všechno co je nad tím o té měně ani neví. Pokud nevyhovuje konkrétní FS, tak díky VFS jej mohu kdykoliv vyměnit za jiný FS a všechno bude fungovat. Pokud píšu v SQL standardu, tak můžu kdykoliv vzít jinou SQL DB splňující standard. Pokud používán REST API, snadno vyměním server nebo klienta. Toto jsou zásady správného návrhu. Nikoliv "chci tamtu technologii".
Takže přínosem je mít možnost, i když se ta možnost možná nevyužijeJaktože se nevyužije? Mít funkční RBD v kernelu přece znamená, že si to můžu zařadit do protfolia dostupných blockdevice a potom to připojovat třeba do lvm, nebo nad tím udělat libovolný fs apod. Klidně to může být PV pro LV a nad tím virtuálka.
Stejný argument ale můžete použít třeba pro webový prohlížečNo samozřejmě. Tak zrovna "http driver" by nemusel být v jádře, bohatě by stačila oddělená dynamická knihovna, kterou by ostatní prohlížeče obecně používaly. Jak se to ostatně běžně dělá u všeho jiného (málo co si implementuje vlastní jpg, png apod knihovny, ale linkují si to).
No ale cílem přece není používat nějakou konkrétní technologii. Resp ano, znám lidi, kteří objeví nějakou úžasnou (pro ně) technologii a potom se pokouší ji nějak za každou cenu použít. Já to dělám přesně naopak, já si nakreslím co chci dosáhnout, stanovím si podmínky a až potom na to hledám technologie.No samozřejmě. A v tomhle případě, o kterém se bavíme, je, že chcete postavit virtualizační řešení (compute nody + storage), hledal jste technologie a nejlepší storage (tj. má nejlepší poměry cena/výkon a takové) neumí obecné připojení, pouze připojení do těch virtuálek. Stále tvrdím, že když se obecné připojení v praktickém nasazení používat nebude, je iracionální tuto storage z výběru vyřadit (tj. dát možnosti obecného připojení tak velkou váhu, že bude tato storage vyřazena)
Což mimochodem kromě jiného umožňuje ty technologie snadno nahrazovat. Pokud nevyhovuje mdadm, nasadím tam hw raid a udělám pvmove.Dobře, to bych i bral, i když mám docela pochybnost o možnostech praktické realizace. Zatím vždycky, když jsem na tuhle potřebu narazil, tak to skončilo na tom, že v tom serveru už nebylo místo na disky, které by se do toho hw raidu daly připojit. Takže žádné pvmove.
Mít funkční RBD v kernelu přece znamená, že si to můžu zařadit do protfolia dostupných blockdevice a potom to připojovat třeba do lvm, nebo nad tím udělat libovolný fs apod. Klidně to může být PV pro LV a nad tím virtuálka.Ohledně LV pro virtuálku už jsem mluvil, nedává to smysl, zavádíte si omezující abstrakci a vrstvy navíc (volume manager nad volume managerem) a získáváte za to teoretickou výhodu, která ovšem nemusí dojít praktického využití (a kdyby náhodou taková potřeba vznikla, je to řešitelné jinak) Nepopírám, že možnost připojit to i jako blokové zařízení v kernelu by byla nice-to-have, ale z toho, že není (tj. ne skrz kernel), bych řekl, že prostě není poptávka. A případy, kde by byla, dost možná má řešit to iSCSI.
Tak zrovna "http driver" by nemusel být v jádře, bohatě by stačila oddělená dynamická knihovna, kterou by ostatní prohlížeče obecně používaly.Když tak nad tím přemýšlím, prohlížeče možná nebyly ten nejlepší příklad, protože tipuju, že ty si zrovna budou hrát na vlastním písečku. Ale dobře, řekněme, že používají dynamickou knihovnu a jádro HTTP neumí, tudíž si nemůžete připojit filesystém přes WebDAV. To asi nikoho nepřekvapuje a nikdo to nepovažuje za velkou závadu. U Cephu je pak situace analogická, existují dynamické knihovny, které "prohlížečům" Qemu nebo třeba rbd-fuse umožňují připojit se k Cephu a jádro Ceph neumí, tudíž si nemůžete připojit filesystém na RBD. Znovu, bylo by to nice-to-have, ale vývojářů ani peněz není neomezeně...
Stále tvrdím, že když se obecné připojení v praktickém nasazení používat nebude, je iracionální tuto storage z výběru vyřadit (tj. dát možnosti obecného připojení tak velkou váhu, že bude tato storage vyřazena)Viz výše. V tom jednom projektu se to obecné připojení nevyužije, ale může se využít jinde. A pokud ne, tak je zbytečné tuto technologii nasazovat jen na jeden projekt, když je možné použít i jiné, stávající řešení.
Dobře, to bych i bral, i když mám docela pochybnost o možnostech praktické realizace. Zatím vždycky, když jsem na tuhle potřebu narazil, tak to skončilo na tom, že v tom serveru už nebylo místo na disky, které by se do toho hw raidu daly připojit. Takže žádné pvmove.Nejde o lokální disky, připojí se sas řadič, externí pole a hurá na přesun. Dělal jsem to několikrát. Funguje to normálně za běhu, akorát je dobré tomu IO trochu odlehčit a nedělat to ve špičkách. (Lze to dělat po jednotlivých LV, takže není potřeba dělat vše naráz.)
U Cephu je pak situace analogická, existují dynamické knihovny, které "prohlížečům" Qemu nebo třeba rbd-fuse umožňují připojit se k Cephu a jádro Ceph neumí, tudíž si nemůžete připojit filesystém na RBD.Tak zrovna u podobných systémů by člověk očekával, že to jako první půjde připojit jako normální fs (cephfs) a když už to umí i blockdevice, tak i ten. Ale tak to je jedno, už to nemusíme opakovat.
Tak zrovna u podobných systémů by člověk očekával, že to jako první půjde připojit jako normální fs (cephfs) a když už to umí i blockdevice, tak i tenTo bych neřekl, v jádru je to velká key-value databáze, takže bych jako první očekával, že naopak nic z toho nepůjde, protože v datech vlastně žádný filesystém není. Teprve jako druhé by bylo to blockdevice - to je přece jenom relativně jednoduché udělat s klíčem zařízeníX-blok-od-0-do-4MB. Postavit na tom filesystém musela být docela pakárna.
To bych neřekl, v jádru je to velká key-value databáze, takže bych jako první očekával, že naopak nic z toho nepůjde, protože v datech vlastně žádný filesystém není. Teprve jako druhé by bylo to blockdevice - to je přece jenom relativně jednoduché udělat s klíčem zařízeníX-blok-od-0-do-4MB. Postavit na tom filesystém musela být docela pakárna.Ano, s tím souhlasím a už v komentáři #70 jsem psal, že si myslím, že objektové S3 API bude nejlepší, ale to by se ceph nesměl prezentovat i tím blockdevice a fs. Tak snad to někdy bude hotové.
Ale dobře, řekněme, že používají dynamickou knihovnu a jádro HTTP neumí, tudíž si nemůžete připojit filesystém přes WebDAV.Jádro umí FUSE, takže si v user space spustíme souborový systém a skrze jádro ho připojíme jako každý jiný, takže programy nemusí řešit knihovny a mohou normálně přistupovat k souborům. Je tam nějaký overhead s přecházením do jádra a zpět, ale jinak to funguje velice pěkně.
zatím bez problémůJsou věci, které by člověk neměl říkat předtím, než se pustí do upgrade na novou verzi... Ne že by se to nepovedlo, ani jsem nepřišel o data, ale jeden z nodů se prostě zbláznil, začal usilovně hrabat po discích, ale nedělal nic. Pořád je to víceméně experimentální nasazení, takže jsem tomu následně trochu pomohl k pádu (odpadní hardware taky nepomohl) a vedlo to na hodinový výpadek Nic, z čeho by se nedalo zotavit, ale začínám mám pocit, že ta věc není dělaná k tomu, aby si to člověk spravoval sám... ale k tomu, aby si to koupil jako open-source blackbox. To se mi, přiznávám se, teda moc nelíbí...
Pro mě je jediné storage řešení na úrovni RAID-10. V případě btrfs multidevice raid-1.Jak tohle funguje? Vytvoříš btrfs přes 50 disků a nastavíš data na raid1? Pak btrfs bloky rozhazuje mezi disky náhodně, takže když odejdou libovolné dva současně, tak jsi o něco přišel?
A když tohle admin ví, tak tam nebude dávat tolik disků, aby bylo riziko, že vypadnou dva současně.Právě naopak. Žádoucí je větší počet disků. Data jsou pak víc rozptýlená a to znamená menší pravděpodobnost, že se při selhání dvou disků současně něco ztratí dřív než se to stihne zreplikovat. Podmínkou je ale pochopitelně, že to pole není obsazeno na plný knedlík. V podstatě by nemělo zaplnění dojít k hranici, kterou je kapacita disků, zmenšená o 2 disky s největší kapacitou, dělená dvěma. Prakticky. Mám-li kombinaci 2x3TB a 12x2TB, je teoreticky celková kapacita 30TB, jelikož ale mohou chcípnout zrovna ty 3TB disky, mohu reálně počítat jen 24TB, což při Btrfs v módu raid1 znamená že pokud tam navalím víc než 12TB tak riskuji že se mi něco ztratí dřív než se to stihne obnovit. Pokud jde o chcípnutí dvou disků současně, tak je za normálních okolností téměř nepravděpodobné. Pokud se něco takového stane, tak je mnohem větší pravděpodobnost, že je chyba jinde – napájení, kabel, deska,… A v takovém případě pokud se disk opět objeví, se data neztratí – prakticky vyzkoušeno. Kdysi jsem totiž používal zdroj, který měl modulární kabely – nebrat! – a stačilo lehce zavadit o některý z nich, aby pokles napájení vyřadil 2 disky z MD raid6, načež následovalo cca 9 hodin modlení aby to zbývající disky ustály. Po nasazení Btrfs v raid1 to nebylo nutné. Uloženým datovým blokům na vypadlých discích se nestalo nic a nové se poté co ty disky odpadly uložily na ty co zůstaly.
zdroj, který měl modulární kabely – nebrat!Jo, kdyby si tak člověk mohl vybírat...