Dotaz: Jak přepsat volné místo na disku

[Laik]

Ahoj, poradí prosím někdo příkaz, jak přepsat volné místo na disku se systémem Debian (serve bez grafiky)? Jsem naprostý laik. Děkuji

Odpovědi

[Petr Tomášek]

Ja bych proste tak dlouho zapisoval nahodne neco do nejakeho souboru (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)...

[jasom]

najjednoduchsie bude dd if=/dev/zero bs=1M of=/subor/vo/filesysteme. pokial chces zabranit restoru vymazanych suborov, bolo by fajn siahnut po nejakom specializovanom nastroji.

[jasom]

mozno by to slo skombinovat so shredom, cize za prikazom uvedenym vyssie spustit: shred -v /subor/vo/filesystems

[Andrej]

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?

[2012]

jako uplne kompletne cele treba nulami? vzit live dvd s linuxem, pustit terminal a:

dd if=/dev/zero of=/dev/sda bs=1M

pokud 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=1

coz ti smaze jen partition tabulku, a nejakej kousek za ni...

[manasekp]

on chce ale prepsat jenom volne misto

OP: toto nespoustej.

[2012]

jsem to pochopil tak, ze chce to misto uvolnit :) ostatne mozna by neskodilo, kdyby autor prispevku upresnil co vlastne potrebuje

[Kit]

http://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux

[Andrej]

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.)

[kohn]

Proto rozumní lidé nepoužívají moderní filesystémy s copy-on-write

[Kit]

Proto rozumní lidé šifrují data. Je jim pak jedno, jaký tam bude filesystém.

[marbu]

+1

[Andrej]

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í.

[Josef Kufner]

Na druhou stranu moderní filesystémy podporují trim, takže by mohlo jít přepsat nepoužívané volné místo na úrovni blokového zařízení, pokud tedy lze zjistit, které bloky jsou označené jako nepoužívané.

[marbu]

Jo, chtel bych videt, jak nekdo obnovuje smazana data na ssd sifrovanem pres dm-crypt, na kterem je btrfs a povoleny discard (spousteny cronem jednou denne/tydne).

[Jendа]

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

[Andrej]

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.

[Jendа]

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.

[Andrej]

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.

[Jendа]

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 ;)

[pavlix]

A nebo použít LXC ;)

Docker, woe.

[Jendа]

Ještě horší.

[pavlix]

Horší než co?

[Jendа]

Chtěl jsem napsat horši než LXC, ale tam jsou ty problémy s nedostatečnou izolací taky. Takže asi nic.

[pavlix]

Jsou postavené nad stejnými vlastnostmi kernelu, takže nějaký článek o tom, že je docker potřeba zabezpečit selinuxem LXC opravdu moc nepomůže :).

[Andrej]

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.

[Jendа]

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ů…

[Andrej]

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.)

[nobody]

z tve arogance se zas jeden po... :) ja hlasuju za zakazani registrovaneho fosilniho Andreje, jeho trolovani je horsi nez nekolik desitek neregistrovanych, mozna jen nopac byl horsi :)

[Andrej]

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…

[karlik]

Mohl bys napsat, na kolika (desítky, stovky, tisíce, desetitisíce) strojích, které administruješ, používáš ZFS/Btrfs? 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í, poškození disku, zaplnění disku na 100 procent a další)? Používáš Linux, Solaris nebo systémy typu *BSD či UNIX? Pokud linux, jakou distribuci?

[Jendа]

Za sebe:

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í disku

Přijde mailem alert, vymění se a nový se přidá do pole.

zaplnění disku na 100 procent

To 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.

[Andrej]

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.

[Andrej]

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.

[Andrej]

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.

[Andrej]

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é.

[marbu]

Zrovna u btrfs si nejsem jistý, jestli bych chtěl nedostatek místa na disku vůbec vyvolávat.

[Andrej]

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.)

[Jendа]

A už vymysleli RAID5/6? (vážně míněná otázka, je to momentálně jediný blocker, proč ho na nový server nedám)

[Jendа]

Nevypadá to zas _tak_ strašně, jako před rokem…

[Andrej]

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í.

[GeorgeWH]

moze mi niekto vysvetlit, ako sa "naprostý laik" dostane na server a ma za ulohu nieco, o com nema ani sajnu. a teraz nerypem, pytam sa vazne.

[Kit]

To je jednoduché. Pronajmeš si virtuál a najednou na tebe místo ikon na ploše kouká příkazová řádka.

[ByCzech]

Divné, mě taky nenapadlo pronajmout si ponorku, když s ní neumím

[GeorgeWH]

+1

[lertimir]

No z další diskuse je zřejmé, že mu někdo poradil že se dá větrat otevřeným poklopem. A udělal to v potopené ponorce.

[H7]

Určitě pomůže vytvoření největšího možného souboru s náhodnými daty? Tedy nezůstanou data např. v blokách filesystému, které nejsou zcela obsazené jiným souborem apod.? Řekl bych, že bude dost záležet na filesystému. Také třeba u nějakého filesystému narazí na limit max. velikosti souboru.

[Laik]

Tak jsem spustil příkaz

dd if=/dev/zero of=/dev/sda bs=1M

ted 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

[manasekp]

Srsly? Pred 6 hodinama jsem ti psal nedelej to. Dobre ti tak, kdyz uz nevis co delas tak si aspon precti navod k tomu co spoustis.

[Laik]

Proto jsem se ptal na foru a četl jsem to až teď, spustil jsem to šel jel jsem pryč. A co se teda stalo, nepřišel jsem o data, že ne ?

[manasekp]

spustil jsi to z toho systemu ktery mas na HDD nainstalovany nebo z neceho externiho? V prvnim pripade to nejspis smazlo k cemu se to dostalo, kazdopadne si myslim ze toho moc nezbylo. Druhy pripad je uplny konec

[Peter Golis]

Nie, neprišiel. Ak boli tie dáta cenné, tak ich máš zálohované a obnova je chvíľková záležitosť.

[Kit]

Bylo tam napsáno, že to nemáš spouštět? Bylo. Máš disk přepsaný nulami. Můžeš si tam teď nainstalovat, co chceš.

[\\]

jedna z výhod linuxu je ta, že téměř ke každému příkazu zadávanému na příkazové řádce existuje manuálová stránka, která popisuje co ten příkaz dělá a jak se ovládá. Takže například, když si ve fóru přečtu, že mám spustit příkaz 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á.

[Trubicoid]

No mozna jeste neco na disku zustalo, ten dd se moh zastavit a neprojet disk nulama az do konce, nebo?

Zkus obnovit partition table a mrknout, jestli neco nahodou nezbylo.

[\\]

Psal, že "Tak jsem spustil příkaz 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á.

[NoXO]

jestli tazatel spustil dd .../dev/sda, tak je chudák..., jako by jste dali pistoli dítěti.

jinak nemám to vyzkoušeno, ale toto je snad ono, nedávno jsem se po takovém nástroji koukal.

"zerofree"...

http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html

[Josef Kufner]

Pokud tě trápí bezpečnost dat, asi by bylo vhodné disk zašifrovat. To lze udělat i bez kopírování dat jinam, ale máš na to jen jeden pokus 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.