Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
21.1.2014 16:04
| Přečteno: 1774×
| Za vším hledej Linux
| 
| poslední úprava: 21.1.2014 16:08
Je tomu víc jak rok, co jsem sepsal blogpost na téma "Btrfs jako systémový FS na notebooku". Už ani nevím, proč jsem jej tenkrát nepublikoval. Natrefil jsem teď na ten odložený zápisek, protože se chystám k výměně původních 60GB SSD disků za novější, a tak mě napadlo, že by se snad přeci jenom mohly tyto informace - včetně shrnutí stávajících zkušeností - hodit.
Btrfs je souborový systém, o kterém mají mnozí stále své pochybnosti, které jim nehodlám vyvracet. V tomto blogpostu chci objasnit proč jsem na Btrfs přešel na svém notebooku.
Změna byla spojena s výměnou klasického rotačního disku o velikosti 500GB za dva zrcadlené 60GB SSD disky. Kapacita původního rotačního disku totiž pro mne byla nebezpečně velká. Maximální objem dat, které se v mém diskovém prostoru za den protočí totiž obvykle nepřekračuje 10GB a dostatek místa tak zbytečně svádí k odkládání dat " které zpracuji až si najdu volnou chvilku". Jenže ta se obvykle nenajde. Takže vždy po nějakém čase tvoří plných 85% dat, z téměř zaplněného disku, věci o kterých už ani nevím že tam jsou.
Zálohování takového disku, je zbytečně zdlouhavé a navíc dříve vedlo k tomu, že se v zálohách hromadila data ve kterých už se mohlo vyznat jen prase.
Někdo by mohl namítnout proč místo jednoho rotačního disku hned dvě SSD? Nemohu říct, že bych někdy měl zásadní problém s rotačním diskem na notebooku. Ale na rozdíl od chcíplého SSD disku se z něj vždy podařilo data vylovit. Nový pracovní notebook jsem si tedy cíleně vybral tak, aby měl možnost přidat místo DVD mechaniky rámeček s druhým diskem. Přechod na nový stroj byla ideální příležitost k otestování chování Btrfs na kořenovém systému, neboť pokud by nastal nějaký problém, byl stále k dispozici stroj původní.
Btrfs používám k naprosté spokojenosti už pět let. Do té doby jsem však měl datové bloky vždy v single módu. Robustnost Btrfs spočívá v tom, že i když pracuje s jedním blokovým zařízením, používá automaticky duplikaci pro systémový superblok a metadata. Samotná data však duplikována nejsou. Je-li tímto blokovým zařízením přímo fyzický disk, se sice výrazně sníží pravděpodobnost ztráty informace o uložených datech, ale poškodí-li se blok s daty, skončí pokus o jejich čtení chybou. Je-li však blokovým zařízením pole RAID-1, které je schopné poškozený datový blok rekonstruovat z mirroru ovšem ke ztrátě dat dojít nemusí.
Bohužel při použití SSD disků má klasická kombinace RAID+LVM + souborový systém nedostatek v tom, že souborový systém, který je nad LVM o nich nic neví. Takže nelze použít možností FS pro práci s SSD. Což už by dnes nemusel být takový problém, ovšem generace SSD disků které jsem použil s tím ještě problémy mít mohla. Proto jsem se rozhodnul vyzkoušet Btrfs v módu raid1 a tím se zbavit nižších vrstev.
Současná verze Btrfs už má mít podporu také pro raid5/6 ale u mého notebooku bylo jasné že víc než dva disky stejně mít nebude. Tudíž v úvahu mohl připadnout stejně pouze mód raid1.
Přeskočím martyrium slepých uliček, abych rovnou přešel k věci. Od linuxového kernelu 3.7, lze datové bloky u Btrfs překonvertovat kdykoliv i dodatečně, takže je zbytečné ihned formátovat Btrfs na raid1, jak jsem to původně udělal já. Takže stačí pouze přidat nový disk /dev/sdb, vytvořit na něm diskový oddíl a ten naformátovat na Btrfs:
mkfs.btrfs /dev/sdb1
Po naformátování jej lze namountovat a buď na něj systém překopírovat rovnou, nebo chcete-li využívat možností snapshotování, vytvořit subvolume a data přesunout až do něj.
Pokud použijete stejně jako já subvolume, Je třeba pro kořenový systém v souboru /etc/fstab změnit nejenom typ souborového systému na Btrfs, ale také přidat volbu subvol s cestou k subvolume. Záznam pak může vypadat kupř. takto:
/dev/sdb1 / btrfs ssd,discard,subvol=/btrfs-system 0 0
Také je v tomto případě třeba upravit parametry, které jádru předává zavaděč. Používáte-li grub, tak jako já, pak by měl /boot/grub/grub.cfg aktuálnímu jádru rovněž předávat parametr subvol
linux /btrfs-root/boot/vmlinuz-3.9.3.0 root=UUID=8d567f20-2ab3-436e-a52f-c7ed7e1c8879 ro rootflags=subvol=btrfs-system quiet
Pak - aniž by bylo nutné měnit cokoliv dalšího na úrovni systému - stačí po restartu přidat druhé fyzické zařízení.
btrfs device add /dev/sdb1 /
Teprve až když je do Btrfs FS přidáno další zařízení, je pro metadata a superblok automaticky změněn profil z DUP na RAID1. Prakticky to znamená, že se původně duplikované bloky rozhodí mezi stávající a nově přidané zařízení. To ovšem neplatí pro uložená data! Ta i nadále zůstanou kde jsou, v režimu single.
Konverzi všech datových bloků na raid1 a přesun duplikovaných bloků dat na druhé zařízení lze provést pomocí balancování.
btrfs fi balance start -mconvert=raid1 -sconvert=raid1 -dconvert=raid1 -f /
Kdyby by bylo provedeno vybalancování bez uvedených parametrů, tak by se bloky s daty z profilu single konvertovaly na profil raid0 a k duplikaci by nedošlo!
POZOR! Aby bylo možné provést konverzi na profil raid1, při kterém se zduplikují všechny datové bloky na druhé blokové zařízení, tak musí být jeho disková kapacita minimálně stejná jako u primárního disku!
Použití Btrfs v módu raid1 má několik výhod. Jelikož se replikují přímo datové bloky, lze bez problému použít různě velká fyzická zařízení, ovšem po konverzi FS na plný raid1, při kterém se replikují všechny datové bloky je maximální dostupná kapacita souborového systému limitována velikostí menšího z nich.
Zjistit kolik volného místa je vlastně k dispozici je u Btrfs prakticky nemožné. Nikdy totiž nelze s určitostí říct, kolik místa výhledově celkem zaberou metadata a uložená data. Výsledek bude vždy závislý na více faktorech:
Navíc při použití Btrfs v raid1 módu je výsledek příkazu df vždy pouze orientační, protože ukazuje kolik procent z celkové kapacity je v rámci souborového systému ještě volných. Ale ani to nemusí být vždy pravda, pokud se používají snapshoty. Skutečný objem uložených dat v adresáři lze zjistit pouze příkazem du
Kolik místa na disku je zabráno ve skutečnosti lze zjistit pouze přes:
root@stroj~# btrfs fi df / Data, RAID1: total=35.00GB, used=28.99GB System, RAID1: total=32.00MB, used=12.00KB Metadata, RAID1: total=3.00GB, used=820.91MB root@stroj:~# df -h / Souborový systém Velikost Užito Volno Uži% Připojeno do /dev/disk/by-uuid/8d567f20-2ab3-436e-a52f-c7ed7e1c8879 100G 60G 36G 63% / root@stroj:~# du -shx / 30G /
Jednou z velmi užitečných věcí Mac OS, která už nejednomu uživateli tohoto systému zachránila zadek, je Time Machine. Nebudu zabíhat do detailů. V podstatě jde o zálohovací mechanismus, který v pravidelných intervalech vytváří inkrementální zálohu systému. Neprovádí však zálohu všech souborů, ale pouze těch které byly změněny, kdežto na ostatní udělá pouze hardlink. I když celá operace probíhá na aplikační úrovni, je poměrně rychlá, neboť přehled o aktuálních změnách udržuje přímo systém. Tudíž nemusí procházet jako rsync celou strukturu a kontrolovat časové razítko.
Tyto zálohy pak lze procházet jako normální souborový systém a data z nich v případě potřeby obnovit.
Snapshoty u Btrfs mohou nabídnout podobnou podobnou funkcionalitu. Pokud je celý systém na samostatném subvolume, které lze snapshotovat, stačí mít malý snapshotovací skript, běžící jako démon, nebo spouštěný v pravidelných intervalech cronem. Existuje i snapshotovací utilita Autoscan, ale s tou nemá žádné zkušenosti.
Pokud si někdo myslí, že u Btrfs stačí pro uvolnění místa smáznout největší soubor, jak je zvykem u jiných FS, tak může být nemile překvapen. Pokud totiž používá snapshoty a datový blok smazaného souboru je součástí některého ze snapshotů, tak se z disku odstraní až v okamžiku, kdy bude odstraněn i ze všech snapshotů.
Bohužel ve chvíli, kdy je souborový systém zcela zaplněný už zbývá pouze jediná možnost - rekomprese datových bloků. Takové situaci se ale dá předejít nastavením kvót. Aktivaci či deaktivaci kvót lze provést kdykoliv, pouze je třeba mít na paměti, že se při jejich deaktivaci veškeré nastavení kvót zahodí. Jestli má váš Btrfs FS kvóty aktivovány lze zjistit zcela triviálně:
root@stroj~# btrfs qgroup show /
Pokud jsou kvóty aktivovány, tak vyjede seznam subvolume. Pokud nejsou, tak příkaz skončí chybou. Aktivace kvót je jednoduchá, navíc sebou jako bonus navíc přinese možnost zjistit skutečný objem dat v subvolume:
root@stroj~# btrfs quota enable
Každé subvolume je v seznamu identifikováno přes svůj qgroupid, což je kombinace čísla úrovně skupiny kvót a čísla "Object ID" příslušného subvolume. Důležitá informace: Ve výchozím stavu má každé subvolume limit neomezený.
Jsou-li aktivovány kvóty a připojený systém je umístěn na subvolume, lze nastavit limit přímo na kořen.
btrfs qgroup limit 35G /
Jinak je třeba (u namountovaného FS) uvést cestu k subvolume, nebo jeho qgroupid. Velikost nastaveného limitu se pak ve vypsaném seznamu zobrazí ve sloupci max_rfer. Není-li řečeno jinak, je limitován objem komprimovaných dat subvolume. Jeho aktuální hodnota je ve sloupci rfer.
Limitovat lze ale také nekomprimovaný objem dat v subvolume - ten se uvádí ve sloupci excl. Tyto hodnoty se mohou docela dost lišit, ale o tom více v oddíle věnovaném uvolnění místa na Btrfs FS. Teprve při práci s kvótami získáte konkrétní představu, jak hrubě orientační je údaj který vrací příkaz df.
Pozor! Podrobný výpis kvót umí dělat až novější verze btrfs-tools > 3.12
Jak už bylo zmíněno - pouhým smazáním největšího souboru k uvolnění místa nemusí dojít. Lepší výsledek poskytne rekomprese datových bloků. Tak jak má každý datový blok u Btrfs svůj vlastní profil, kterým je řečeno jak se s ním má zacházet (jestli se má duplikovat nebo ne), tak se u něj udržuje informace o použité kompresi. Je-li disk namountován bez upřesnění parametrů, jsou datové bloky komprimovány v závislosti na vytížení systému a dosaženém kompresním poměru. Pokud je nevýhodný, tak se datový blok uloží bez komprese. V rámci jednoho svazku tak vedle sebe existují datové bloky komprimované i nekomprimované. Kompresi datových bloků lze provádět i dodatečně příkazem defrag, což dává prostor k získání volného místa v případě, že je disk zaplácnutý až po okraj. Kompresi jsem se však již více věnoval v naší wiki
Co naopak z místa na disku může výrazně ukrojit, je defragmentace. V případě, že je aplikována na adresář kde je nějaký snapshot, budou místo inkrementálních datových bloků vytvořeny nové scelené. Čímž dojde k obsazení dalších dat.
Jak jsem zmínil hned zkraje blogpostu - průběžný stav zaplnění disku záhy vystoupal na obvyklých 95%. Takže se data dlouhodobě točí na pouhých 5% čipů. S tím pravděpodobně souvisí i zvláštní stav, kdy systém někdy cca na minutu zmrzne a pouze disky vykazují nějakou aktivitu, pravděpodobně během té doby zřejmě jádro dělá pořádek v mirrorovaných datových blocích. Velkou diskovou aktivitu vykazuje stroj také při vypínání, kdy ukládá nakešovaná data. Podle názoru lidí s nimiž jsem to konzultoval, by mohly pomoci novější SSD disky. Je fakt, že ty 60GB OCZ-VERTEX3 co mám, už za sebou mají téměř dva roky neustálého provozu a podobně se chovaly již v době kdy na nich ještě byl klasický softwarový raid.
Největší výhodou oproti klasickému řešení se SW RAID 1 je, že nedochází k rozpadu pole. Btrfs lépe hospodaří s místem a je velmi odolný i vůči hrubému zacházení.
Tiskni
Sdílej:
btw, tuto informaci mate i na te odkazovane wiki, tam by to mohla opravit chtelo. (vlastne tam je o snaphot-aware zminka, ale o par odstavcu dal tam je ta formulace o duplikaci dat.)
Jen tak na okraj - kdyby snad někdo řešil Btrfs v prostředí Pacemakeru, tak mám napsaného vlastního agenta, pro mounting souborových systémů, který nemá - na rozdíl od oficiálního agenta Filesystem - problém s Btrfs volume.
Ona se z toho někdy ztrácela?
22.1.2014 08:46
Max | skóre: 72
| blog: Max_Devaine
root@lukas:~# time fstrim -v / /: 12347772928 bytes were trimmed real 0m29.471s user 0m0.000s sys 0m0.312s root@lukas:~#Podrobnosti ako pouzivam SSD na mojom notebooku mam na svojej Wiki. Daj potom vediet, ci to odlozene "trimovanie" pomohlo.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz