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í.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
patrně s právy root spustit :
tune2fs -m 0 /dev/sdXy
rezervuje 0% bloku pro roota viz manual tune2fs
hm nez jsem to dopsal uz tu byla najednou odpoved :) jen dodam ze nemusis formatovat znova..tohle staci provest hned i s daty na disku..v podstate to jen zmeni ty rezervovane bloky..filesystem se nezmeni
no podle tohoto vypada ze ma ten filesystem skutecne velikost "jen" 917GiB z toho 200M pouzito.. nejde v gparted zvetsit ? v prostoru uz neni zadne volne misto za ci pred oddilem ? treba fdisk by mohl byt napomocny pokud gparted zlobi..
fdisk -l /dev/sdb
sudo fdisk -l /dev/sdb
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x372c0fdb
Device Boot Start End Blocks Id System
/dev/sdb1 1 121601 976760001 83 Linux
Hlavní část toho prostoru tovří nutná informace, které sektory jsou volné, a jak je soubor rozprostřenNemyslis ze 14GB pro tyto informace je nejak moc?
Pokud vidíš ve výpise tune2fs -l: Reserved block count: 0, tak je pro roota rezervováno právě tolik bloků.Jo presne tolik vidim... Akorat jsem se pred pouzitim samotneho programu
tune2fs
nepodival kolik tam bylo predtim, ale jelikoz se po prikazu sudo tune2fs -m 0 /dev/sdb1
neuvolnilo zadne misto tak predpokladam ze Reserved block count: 0
tune2fs
jinak si to vysvetlit neumim.u ostatních FS by tato velikost byla také, ale až po zaplnění datyByla nebyla. Záleží co za data. Pokud tam bude několik málo obrovských souborů, tak ext3 bude mít ještě další overhead jak prase, protože neumí extenty. PS. ještě tady nepadlo že část z těch 14GB je journal.
tune2fs -l /dev/sdb
. Např já mám pro jeden svůj malý oddíl část výpisu
Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1022 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8208 Inode blocks per group: 513Z toho je vidět, že mám 4K bloky,takže po 8 sektorech, jsou seskupeny do skupin každá má 32K bloků (tedy 128M na skupinu), pro každou skupinu je 8k inode a inode zabirají 513 bloků, Takže 513/32768 je ztráta v alokační struktuře, tedy asi 1,8%. Ještě brutálnější výpis se dostane pomoci
dumpe2fs /dev/sdb
kdy to jde přímo na alokované bloky.
A to se zeptám ještě jestli tomu někdo rozumí. dumpe2fs
mi v některých skupinách ukáže, že mám 0 volných
inode a nějaké volné bloky. Znamená to, že se k těm volným blokům už nejsem schopen dostat, protože skupina už nemá volné inode a pak je není schopna přidělit k souboru? Nebo je mohou přidělit souborům i inode z jiných skupin?
Group 148: (Blocks 4849664-4882431) [ITABLE_ZEROED] Checksum 0xc153, unused inodes 0 Block bitmap at 4718596, Inode bitmap at 4718612 Inode table at 4720676-4721188 3757 free blocks, 0 free inodes, 642 directories Free blocks: 4862077-4862101, 4862194-4862975, 4863066-4863076, 4872938-4873215, 4873307-4873330, 4873597-4873727, 4873903-4873983, 4874129-4874164, 4874203-4874751, 4874936-4874990, 4880094-4881056, 4881261-4882082 Free inodes:
Tiskni Sdílej: