Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
28.10.2014 15:21
Petr Tomášek | skóre: 39
| blog: Vejšplechty
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
cat /dev/urandom > /tmp/soubor), dokud system nezarve, ze uz na disku neni misto.
Pak soubor smazat. Vzhledem k moznosti rozhozeni systemu bych to delal v jednouzivatelskem rezimu (teda, jestli systemd neco takoveho jeste umi, hihihi)...
dd if=/dev/zero bs=1M of=/subor/vo/filesysteme. pokial chces zabranit restoru vymazanych suborov, bolo by fajn siahnut po nejakom specializovanom nastroji.
shred -v /subor/vo/filesystems
Proč se všichni snaží používat dd tam, kde stačí prostě cat a přesměrování? To je nějaká divná nová móda nebo co?
dd if=/dev/zero of=/dev/sda bs=1Mpokud to chces z duvodou, ze je tam jen nejaky filesystem, a ty ho chces odstranit, postaci:
dd if=/dev/zero of=/dev/sda bs=1M count=1coz ti smaze jen partition tabulku, a nejakej kousek za ni...
OP: toto nespoustej.
To ovšem fungovalo jen na těch muzejních filesystémech typu Ext{2,3,4}, které přepisovaly data „na místě“, tj. při změnách souboru nezapsaly data jinam, jak by člověk čekal, ale psaly je opravdu rovnou do původních bloků toho souboru. Na moderním filesystému s copy-on-write a checksumy (ZFS, Btrfs) žádné z těch rádoby-secure utilit nefungují. (Pouze dělají, že něco dělají, což může být horší, než kdyby nedělaly nic.)
Ne, to jim není jedno. Pokud má být smazání souboru opravdu bezpečné, má poskytovat jakousi extra záruku, že smazaný soubor už tam nebude v žádné podobě, kterou by kdykoliv kdokoliv jakkoliv mohl získat zpět. Tedy i kdyby někdo (jakýmkoliv způsobem, třeba střelnou zbraní u hlavy) překonal šifrování, bezpečně smazaný soubor už nesmí být technicky možné obnovit.
U fosilních filesystémů se na něco takového dá spoléhat. (Stejně jako se dá spoléhat na to, že budou dřív nebo později obsahovat nekonzistentní soubory a nikdo si toho nikdy nevšimne.) U filesystémů hodných 21. století bohužel zatím žádné bezpečné mazání není k dispozici. Ne že by nebyly patche, které rozšiřují kernel a základní utility způsobem, jaký dnes funguje například u cp --reflink (jen jde tentokrát o rm), ale pokud vím, neexistuje nic, co by bylo běžně k dispozici u většiny distribucí.
Bezpečné mazání na Btrfs by se možná dalo realizovat takto, pokud tam ovšem není nějaký další podezřelý chyták:
mount -o remount,nodatacow /home # nebo zkrátka kterýkoliv jiný mountpoint srm něco # konkrétních utilit existuje víc mount -o remount,datacow /home # návrat zpět do normálu
Tento problém nemusí být tak zásadní, jak by se mohlo na první pohled zdát, ale je třeba s ním při zabezpečení dat počítat. Výhody moderního filesystému ve srovnání s fosilním jsou ovšem už dnes tak zásadní, že by asi málokdo volil fosilní filesystém jen kvůli „snadnému“ bezpečnému mazání.
30.10.2014 14:44
Josef Kufner | skóre: 70
30.10.2014 15:45
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Stejně jako se dá spoléhat na to, že budou dřív nebo později obsahovat nekonzistentní soubory a nikdo si toho nikdy nevšimne.Na operačních systémech, které nenavrhovala skupina diletantů, se zachovává separace vrstev a neduplikuje se kód, a proto se tam o konzistenci dat na zařízení stará ovladač blokové vrstvy. To, že se na chaotickém fosilním Linuxu někdo rozhodl, že konzistenci dat na blokovém zařízení bude řešit až souborový systém, je totiž úplně k ničemu. Od moderního operačního systému člověk samozřejmě očekává možnost exportovat celé blokové zařízení, nikoli jen soubory. Jenže když exportuje na tom tvém linuxu logical volume, tak už tam není žádné btrfs, které by konzistenci řešilo, a zase se ti to celé rozpadne jak domeček z karet
Separace vrstev je hloupá mantra, kterou někteří slepě opakují, aniž by se nad ní byť jen trochu zamysleli. Už několikrát jsem tu psal, že RAID{1,5,6} dává smysl pouze tehdy, je-li vestavěný přímo ve filesystému. Jinak z jeho výhod zbude jen směšný zlomek. (A písmeno I ve zkratce RAID pak samozřejmě nemůže platit.) Místo opravdové spolehlivosti vede náboženství zvané „separace vrstev“ k pouhému zdání spolehlivosti, což může být (z pohledu zálohovací politiky a dalších souvisejících procesů) nebezpečná situace.
Všimni si, že tvá poslední věta je naprostý blábol postrádající smysl. Nic se nesesype jako domeček z karet. Pokud „exportuju“ (ať už to slovo znamená cokoliv) celé blokové zařízení, protože ho chci například přidělit virtuálnímu stroji jako disk, činím tak s vědomím všech rizik. Uvnitř virtuálního stroje pak samozřejmě poběží operační systém s Btrfs nebo ZFS, který si dovede konzistenci dat na svém virtuálním disku ohlídat. Ideálním řešením je přidělit virtuálním stroji několik logical volumes (vhodně alokovaných podle topologie fyzického úložiště) a nechat ho, aby se o RAID (na úrovni filesystému, samozřejmě) postaral sám. Má totiž víc informací o svých datech a svém filesystému a dokáže tedy využít svá zařízení mnohem efektivněji, než jak by to uměl hostitelský systém.
1.11.2014 17:24
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Už několikrát jsem tu psal, že RAID{1,5,6} dává smysl pouze tehdy, je-li vestavěný přímo ve filesystému. Jinak z jeho výhod zbude jen směšný zlomek.RAID používám kvůli tomu, aby mi to fungovalo, když zhebne jeden (případně dva) disky. Případně ještě pro získání většího výkonu při sekvenčním čtení. To skvěle funguje i bez filesystému. Máš na mysli ještě nějaké jiné výhody?
Uvnitř virtuálního stroje pak samozřejmě poběží operační systém s Btrfs nebo ZFS, který si dovede konzistenci dat na svém virtuálním disku ohlídat.Nedovede, protože nemá přístup k původním diskům. Když tedy RAID nebo on zjistí nekonzistenci, nemá jak zkusit, které disky dávají správná data a které špatná.
Ideálním řešením je přidělit virtuálním stroji několik logical volumes (vhodně alokovaných podle topologie fyzického úložiště) a nechat ho, aby se o RAID (na úrovni filesystému, samozřejmě) postaral sám.To je noční můra. Virtuální stroj mám proto, abych ho mohl bez zásahů zvenku přelejvat mezi různými stroji ve virtualizačním clusteru. Ne, že když ho dám na stroj, který má náhodou jiný počet disků, budu muset spustit komplikovaný rebalance/reshape.
Už několikrát jsem tu psal, že RAID{1,5,6} dává smysl pouze tehdy, je-li vestavěný přímo ve filesystému. Jinak z jeho výhod zbude jen směšný zlomek.RAID používám kvůli tomu, aby mi to fungovalo, když zhebne jeden (případně dva) disky. Případně ještě pro získání většího výkonu při sekvenčním čtení. To skvěle funguje i bez filesystému. Máš na mysli ještě nějaké jiné výhody?
Samozřejmě mám na mysli další výhody a ne jen tak ledajaké. Disk nemusí zhebnout. Může pouze obsahovat špatná data (po problému s napájením, vlivem závady nebo vlivem lidského faktoru (začínající administrátor a dd, začínající administrátor a fdisk)). Striktní dodržení vrstev abstrakce způsobí, že RAID vrací špatná data, leckdy jiná při každém čtení. (Stačí si představit, jak se data čtou prokládaně.) RAID na úrovni filesystému tento problém snadno ustojí. Checksum mu řekne, který z disků má pravdu (ať už je to RAID1, RAID5, RAID6 nebo jiný typ redundance), a blok se pak opraví podle replik (RAID1) nebo podle parity (RAID5,6).
Další výhoda pokročilých filesystémů (ne nutně související s RAIDem, ale přece výhoda) je možnost mít jiný RAID level pro data a metadata nebo dokonce pro různé části filesystému. Kromě elegantního řešení dilemat typu využití místa versus spolehlivost to nabízí ještě jednu pěknou vlastnost — pokud budou například metadata typu RAID1 a data typu RAID0 a jeden z disků v poli odejde, neztratím všechna data. Filesystém bude mountovatelný a některé soubory (ty, které se šťastnou náhodou trefily celé do dostupných bloků) budou dostupné. Právě v malých souborech má člověk leckdy nejdůležitější data… Tohle žádný klasický RAID neumí.
Poslední zajímavou výhodou filesystémů podporujících atomické checksumy a RAID je možnost replikace dat a/nebo metadat v rámci jednoho disku (resp. v rámci každého z disků pole). U dat to (kromě hodně důležitých subvolumes) až tak velký smysl nedává, ale u metadat to může výrazně pomoct, když se (a) objeví vadné bloky nebo (b) filesystém poškodí nějakým neopatrným zásahem — někdy se člověk nestačí divit, co všechno lidský faktor umí způsobit.
Uvnitř virtuálního stroje pak samozřejmě poběží operační systém s Btrfs nebo ZFS, který si dovede konzistenci dat na svém virtuálním disku ohlídat.Nedovede, protože nemá přístup k původním diskům. Když tedy RAID nebo on zjistí nekonzistenci, nemá jak zkusit, které disky dávají správná data a které špatná.
Buď k nim přístup bude mít (což se zatím v tolsetech všeho druhu příliš nepodporuje a už vůbec ne v souvislosti s migrací, jak správně podotýkáš níže), nebo zkrátka nevyužije všech výhod RAIDu na úrovni filesystému (zejména co se výkonu týká). Virtualizace má výhody i nevýhody a tohle je (zatím) jeden z kompromisů.
Dlužno ale zdůraznit, že pomocí „zvol“ na ZFS můžeš vytvářet a exportovat disková média, která jsou nejen redundantní, ale taky automaticky checksummovaná a tedy odolná proti skrytým chybám disků. ZFS tedy umí zabít dvě mouchy jednou ranou — spolehlivý filesystém na serveru a spolehlivá virtuální média pro virtuální stroje. Kdyby tu diskutoval Jirka Paroubek, zeptal by se ostatních filesystémů: Kdo z vás to má?!
Ideálním řešením je přidělit virtuálním stroji několik logical volumes (vhodně alokovaných podle topologie fyzického úložiště) a nechat ho, aby se o RAID (na úrovni filesystému, samozřejmě) postaral sám.To je noční můra. Virtuální stroj mám proto, abych ho mohl bez zásahů zvenku přelejvat mezi různými stroji ve virtualizačním clusteru. Ne, že když ho dám na stroj, který má náhodou jiný počet disků, budu muset spustit komplikovaný rebalance/reshape.
V tom máš naprostou pravdu. Počet disků fyzického stroje by ale nemusel hrát až takovou roli, pokud by nějaký budoucí virtualizační stack dokázal alokaci disků rozumně zautomatizovat a pokud by počet fyzických disků převyšoval počet virtuálních, což lze očekávat. Do té doby by asi byl schůdným řešením zvol nad ZFS, který se dá (při dodržení správné velikosti) naalokovat na každém stroji jiným způsobem a pokaždé může být distribuovaný, checksummovaný i redundantní, bez ohledu na to, co s ním dělá virtuální stroj.
Faktem ale zůstává, že pokud filesystém ve virtuálním stroji nemá ponětí o topologii úložiště, bude to mít velmi negativní dopad na výkon. Tohle je jeden z nedořešených problémů (současné) virtualizace.
17.11.2014 16:59
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Samozřejmě mám na mysli další výhody a ne jen tak ledajaké. Disk nemusí zhebnout. Může pouze obsahovat špatná data (po problému s napájením, vlivem závady nebo vlivem lidského faktoru (začínající administrátor a dd, začínající administrátor a fdisk)). Striktní dodržení vrstev abstrakce způsobí, že RAID vrací špatná data, leckdy jiná při každém čtení. (Stačí si představit, jak se data čtou prokládaně.)Tohle mi není jasné. Například blokový RAID na AS/400, který rozhodně nemá s FS vůbec nic společného, má checksum na konci každého sektoru. Chápu správně, že by podle tebe taková věc neměla být možná? Nebo snad tento mechanismus nechrání proti silent data corruption?
RAID na úrovni filesystému tento problém snadno ustojí. Checksum mu řekne, který z disků má pravdu (ať už je to RAID1, RAID5, RAID6 nebo jiný typ redundance), a blok se pak opraví podle replik (RAID1) nebo podle parity (RAID5,6).Samozřejmě. Nevidím ale důvod, proč by něco podobného nemohl umět i klasický RAID nad blockdevices. A někdy RAID nad blokovými zařízeními může být výhodnější než souborový RAID. Například pokud ho chci zašifrovat, tak přece nebudu šifrovat patnáct disků každý zvlášť a pak nad nimi stavět RAID (má to různé praktické problémy, například bych pro každý disk asi měl použít jiný klíč, ale kde zas ty klíče skladovat a tak). Nebo pokud je to diskové pole a chci ven prostě vyexportovat několik blockdevice přes iSCSI - klienty nezajímá, že došlo místo a přidal jsem proto dva další disky, nebo jsem naopak místo starých terových disků koupil čtvrtinové množství čtyřterových, a kvůli tomu by si *oni* měli přebalancovat/reshapovat svoje filesystémy. Výhody v dalších dvou odstavcích jsou mi jasné a chápu, že s blokovým RAIDem udělat nejdou. Rozporoval jsem hlavně ty checksumy.
Dlužno ale zdůraznit, že pomocí „zvol“ na ZFS můžeš vytvářet a exportovat disková média, která jsou nejen redundantní, ale taky automaticky checksummovaná a tedy odolná proti skrytým chybám disků.To pak funguje jako checksumovaný blokový RAID, jehož možnost jsi na začátku příspěvku popřel, ne?
Faktem ale zůstává, že pokud filesystém ve virtuálním stroji nemá ponětí o topologii úložiště, bude to mít velmi negativní dopad na výkon. Tohle je jeden z nedořešených problémů (současné) virtualizace.Jo, už jsem si říkal, že bych mohl přestat dávat virtuálům blockdevice, a místo toho jim exportovat rovnou filesystém třeba přes NFS. A nebo použít LXC ;)
17.11.2014 17:26
pavlix | skóre: 54
| blog: pavlix
A nebo použít LXC ;)Docker, woe.
17.11.2014 18:13
Jendа | skóre: 78
| blog: Jenda
| JO70FB
17.11.2014 18:30
pavlix | skóre: 54
| blog: pavlix
17.11.2014 18:36
Jendа | skóre: 78
| blog: Jenda
| JO70FB
17.11.2014 19:17
pavlix | skóre: 54
| blog: pavlix
Samozřejmě. Nevidím ale důvod, proč by něco podobného nemohl umět i klasický RAID nad blockdevices.
Já taky ne. Jistě to nějaký proprietární RAID má. Ale je podstatný rozdíl mezi proprietárním a nepřenositelným řešením a mezi open-source filesystémem, který se dá používat (a případně troubleshootit) na téměř kterémkoliv hardwaru.
Například pokud ho chci zašifrovat, tak přece nebudu šifrovat patnáct disků každý zvlášť a pak nad nimi stavět RAID&hellip
To je ten důvod, proč se pořád někde rojí nápady na šifrování na úrovni filesystému. Reiser4 ho měl, ale po dlouhých hádkách o začlenění do kernelu musel v podstatě celý systém svých rozšíření zahodit. (Dnes už samozřejmě není Reiser4 na pořadu dne — jeho hlavní autor některé věci poněkud pokazil. Fakt, že filesystém, který všechny ostatní (ve své době) porazil snad v každém existujícím benchmarku, se nakonec nedostal do kernelu, je jakési memento, které ukazuje, jak špatně může skončit dobrý projekt.)
…klienty nezajímá, že došlo místo a přidal jsem proto dva další disky, nebo jsem naopak místo starých terových disků koupil čtvrtinové množství čtyřterových, a kvůli tomu by si *oni* měli přebalancovat/reshapovat svoje filesystémy.
Tak tam by pomohl ten ZVOL, který by klienti taky viděli jako jedno transparentní zařízení. (Pak ale přístup od klientů nebude RAID-friendly, když o RAIDu nevědí nic.)
To pak funguje jako checksumovaný blokový RAID, jehož možnost jsi na začátku příspěvku popřel, ne?
Já tu „existencí“ vnímám v trochu širším kontextu. Představoval bych si, že ten filesystém zprovozním na mobilu, na mém notebooku i na farmě serverů a že bude nějakým způsobem přenositelný. Pokud ty checksumy závisí na proprietárním firmware konkrétního RAID řadiče vhodného do konkrétního typu serverů, zkrátka nějak unikají mé pozornosti.
Jo, už jsem si říkal, že bych mohl přestat dávat virtuálům blockdevice, a místo toho jim exportovat rovnou filesystém třeba přes NFS.
Pokud chceš live migratioin, bez sdíleného souborového systému se často neobejdeš. Například virt-manager live migration podporuje, ale disky musí být na výchozím i cílovém systému přístupné na stejném místě. Když jsem live migration naposledy zkoušel, myslím si, že se dokonce požadovalo, aby byly disky v souborech ve stejném mountpointu. Možná se ale dalo dosáhnout téhož efektu pomocí nějakých iSCSI zařízení přístupných na všech strojích — to jsem nezkoušel. (Tam by to ale chtělo, aby se ta zařízení sama on-demand připojovala.)
A nebo použít LXC ;)
Tak jasně, ten sdílený /proc je k vzteku a vůbec toho ještě zbývá spousta vyřešit. Ve srovnání s něčím jako zóny v Solarisu působí LXC dojmem pravěku. Nezbývá než doufat, že se to časem změní. Neumím si ovšem představit, jak se teď LXC bude vyvíjet, protože postupné přidávání izolace bude stále dokola způsobovat, že nějaké existující LXC kontejnery přestanou správně fungovat po každém upgradu kernelu. Svým způsobem jsem rád, že na projektu typu LXC nepracuju.
17.11.2014 20:50
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Já taky ne. Jistě to nějaký proprietární RAID má. Ale je podstatný rozdíl mezi proprietárním a nepřenositelným řešením a mezi open-source filesystémem, který se dá používat (a případně troubleshootit) na téměř kterémkoliv hardwaru.
Já tu „existencí“ vnímám v trochu širším kontextu. Představoval bych si, že ten filesystém zprovozním na mobilu, na mém notebooku i na farmě serverů a že bude nějakým způsobem přenositelný. Pokud ty checksumy závisí na proprietárním firmware konkrétního RAID řadiče vhodného do konkrétního typu serverů, zkrátka nějak unikají mé pozornosti.Ještě v #34 jsi psal, že je to vlastnost těch filesystémů. Já nemůžu za to, že v „moderním“ Linuxu není robustní RAID, který má konkurence minimálně 15 let.
To je ten důvod, proč se pořád někde rojí nápady na šifrování na úrovni filesystému.Překlad: bude rok 2015 a tebou propagované „moderní“ linuxové btrfs a ZFS nemá žádnou možnost, jak zašifrovat data. Alespoň, že si je zloděj může díky checksumům správně obnovit, i když při krádeži toho pole poškodí pár sektorů…
Teď jsem si smíchy usral.
Jasně. Rozumní lidé totiž nepotřebují integritu dat. Vůbec jim nevadí, když mají poškozené soubory a nepřijdou na to. Těm rozumným lidem navíc taky vůbec nevadí, že RAID1 de facto nikdy nefungoval, pokud se týká integrity dat, a že teprve Btrfs a ZFS dovedou se svým vestavěným RAIDem opravdu zjistit, která z replik selhává a která vrací platná data. A především ti rozumní lidé nepotřebují snapshoty, protože oni přece rozhodně nechtějí atomicky zálohovat! Ať je všechno nekonzistentní! Tak to přece má být! Bylo to tak v pětadevadesátém, ať je to tak i dnes!
Kromě jiného soudím, že anonymní trollové by měli být zakázaní. (Už dlouho takto marně parafrázuji onen dávný výrok o Kartágu.)
Prosím prosím, ABCLinuxu, zrušte už tyhle anonymní trolly. Přijde mi, že si jich už všichni užili přespříliš.
Nemyslím si, že bych trolloval. Pouze si nelibuju v neslaných a nemastných žvástech, nazývám věci pravými jmény a nezdráhám se přičinit na hrubý pytel hrubou záplatu, zejména když někdo žvaní nesmysly. Komu se to nelíbí, ať mi…
17.11.2014 17:04
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Mohl bys napsat, na kolika (desítky, stovky, tisíce, desetitisíce) strojích, které administruješ, používáš ZFS/Btrfs?Na jednom
A jaké máš zkušenosti s obnovou při poškození filesystému při neočekávaných událostech (výpadek napájeníJe to CoW, pokud ti nekecá hardware, nic se nestane.
poškození diskuPřijde mailem alert, vymění se a nový se přidá do pole.
zaplnění disku na 100 procentTo jsem ještě nezažil, ale snad nic, ne?
Používáš Linux, Solaris nebo systémy typu *BSD či UNIX? Pokud linux, jakou distribuci?Debian, ZFS on Linux.
Strojů jsou nanejvýš desítky, z toho fyzických tak maximálně jednotky. Je to tak 5 dvousocketových serverů s několika disky. (Před dvěma lety jsem instaloval Btrfs na 8 jiných 2U serverů, ale u toho zaměstnavatele už nepracuju. (Ne, nebyl jsem vyhozen kvůli Btrfs — abych předešel obligátní otázce. Stroje fungují spolehlivě dodnes, pokud je mí známo.)) Na těch současných 5 fyzických strojích jsou virtuálky KVM (celkem asi 30 kousků), které v sobě mají taky Btrfs (Linux) nebo ZFS (FreeBSD, OpenIndiana).
S obnovou při poškození filesystému nemám žádné zkušenosti. Žádné katastrofické poškození filesystému jsem zatím nezažil. Nejhorší situaci, jakou si pamatuju, vyřešil btrfs-zero-log. Šlo o chybu v kernelu, která byla jenom v jedné jediném verzi, než ji v následující zase opravili. Stoprocentní zaplnění jsem zažil několikrát, ale nic špatného se nestalo. (Problém s poškozením při 100% zaplnění jsem viděl na Reiser4, ne na Btrfs.)
Používám Linux s Btrfs a ZFS (ale ze ZFS na Linuxu nebootuju), FreeBSD na ZFS (včetně bootování, tj. modul zfs zavede už bootloader) a OpenIndianu (samozřejmě na ZFS) mám už notnou dobu na noteboku. Jen ji poslední dobou moc nepoužívám, protože už se nezabývám kernelovým hackováním tolik jako dřív.
No, ještě jsem do toho nezapočítal ty 4 notebooky různých členů rodiny a domácí server, ale na to fakt sere pes.
Aha. Ještě jsem neodpověděl na tu distribuci.
Na svých desktopových strojích mám ArchLinux (doma). V práci jsem měl Fedoru (protože to byla jedna z mála distribucí, které tehdejší zaměstnavatel nějak „podporoval“). Časem jsem si ale Fedoru taky celkem oblíbil. Některé systémové nástroje má velmi elegantně integrované do KDE, instalátor podporuje bez problémů Btrfs (bez nutnosti pozdějších hacků nebo konverze filesystému) a je tam implicitně zapnutý a funkční SELinux. (Ten mi třeba pomohl, když si chtěl CUPS kvůli bugu smazat svůj vlastní SSL certifikát s klíčem. Tak díky SELinuxu prostě nemohl.) Ale jak říkám, doma mám ArchLinux i na domácím serveru, protože to je jedna z mála distribucí, ve kterých se dokážu vyznat natolik, aby mě nic zásadního nepřekvapilo. U Fedory už je různých chytrých a rádoby-chytrých nástrojů příliš.
Fedoru mám i na těch fyzických serverech — jeden z nich je platforma Power7 a je super, že má člověk stejné systémové prostředí na Intelech i na Power7. Některé fyzické servery mají bohužel dual-boot s Ubuntu a o jeho občasném nasazení raději nechci nic bližšího vědět. Fedora a Ubuntu sdílejí (Btrfs) filesystém, jen jsou v jiném subvolume (tj. musí mít v kerneolvých optionech někde zapsáno subvol=… a tak podobně).
Na virtuálních strojích je asi tak 20% Fedory, 20% ArchLinuxu, 20% Ubuntu (hrůza pomyslet — můj nápad to nebyl) a zbytek připadá na FreeBSD a OpenIndianu. Tak je to přinejmenším na těch virtuálkách, o kterých vím a o které se starám.
Přepsání volného místa nulami zajistí třeba cat /dev/zero > /soubor/na/disku, případně pokud je cílem přepsat volné místo náhodnými daty, dá se použít třeba cat /dev/urandom > /soubor/na/disku. Je třeba počkat, až příkaz skončí kvůli nedostatku místa na disku. Pak je nutné zavolat sync. U pokročilejších souborových systémů, například Btrfs, zůstane samozřejmě i po tomto úkonu ještě nějaká malá část volného místa, protože odhad volného místa není přesný. Oba úkony lze tedy párkrát zopakovat, nicméně těch pár kilobytů už za to už fakt nestojí. Poté, co proběhl sync, stačí nově vytvořený /soubor/na/disku smazat a volné místo bude opět volné, jen přepsané.
V roce 2009 bych ho vyvolávat nechtěl, zatímco v roce 2014 z toho žádné zásadní obavy nemám. (Btrfs mám na svých strojích od roku 2010.)
30.10.2014 15:48
Jendа | skóre: 78
| blog: Jenda
| JO70FB
30.10.2014 15:50
Jendа | skóre: 78
| blog: Jenda
| JO70FB
V ZFS je RAID 5, 6 i silnější redundance než 6 samozřejmě k dispozici už několik let. (Přinejmenším od roku 2008, ale pravděpodobně i déle.)
V Btrfs RAID 5 i 6 sice vymysleli, ale není ještě připravený pro praktické použití.
dd if=/dev/zero of=/dev/sda bs=1Mted to skončilo a nešlo nic spustit, psalo to pořád not found nebo tak něco, tak jsem to restartoval a po restartu system nenajel. Poradí někdo? Nechci přijít o data
Děkuji
rm -rf /, můžu si přečíst v manuálu man rm, že je to blbá rada a že to nemám dělat. Stejně tak je tomu s dd v tomto případě.
Obávám se, že můžeš udělat datům pápá.
dd if=/dev/zero of=/dev/sda bs=1M, ted to skončilo..."Myslím, že se dá předpokládat, že: - dd dokončil úspěšně svou práci, - tazatel podobnou manipulaci nezvládá.
29.10.2014 12:41
Josef Kufner | skóre: 70
Trik spočívá v tom, že šifrující program to bere blok po bloku a jak jde postupně, čte nešifrovaná data dřív, než je přepíše šifrovanými. Ve výsledku budeš mít jistotu, že tam nic srozumitelného nezbylo.
Tiskni
Sdílej:
