Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Tento blog obsahuje nebezpečnou symboliku.
Utilitka filefrag slouží (zjednodušeně řečeno) pro zjištování fragmentace souborů.
K fragmentaci souborů dochází u každého systému souborů bez ohledu na to, co si myslí jeho příznivci a co o něm říkají jeho odpůrci. Pokud je mi známo, tak ze všech FS dostupných v Linuxu má online defragmentaci pouze XFS (programem xfs_fsr
). U JFS je defragmentace možná pouze na domácí platformě IBM, reiserfs nemá podobný nástroj vůbec a "domácí" ext2, ext3 také ne.
Tento zápisek je především o ext3. Při hledání nějaké pomůcky, která by alespoň trochu umožnovala umravnit soubory na disku jsem v diskusních fórech nacházel v podstatě dva druhy zápisků. Autoři těch prvních tvrdili, že linux není windows a proto ext3 žádný defrag nemá, protože dobře navržený fs jej nepotřebuje. A ti druzí byli již zoufalí (stejně jako já) při pohledu na klesající propustnost při čtení souborů.
Zpět k tématu. Utilitka filefrag
umožňuje zjistit počet fragmentů a na ext3 také odhadne minimální počet fragmentů pro daný soubor a aktuální stav FS. Má pouze jediný přepínač -v
, který vypíše i rozsahy bloků jednotlivých fragmentů. Použítí je snadné:
#filefrag search_index.MYI search_index.MYI: 429258 extents found,\ perfection would be 15 extents
Výstup je přehledný a pro účely statistiky i snadno parsrovatelný. Předchozí příklad ukazuje výstup programu filefrag
a jako figurant je použit soubor o velikosti 1.8GB. Bystřejší čtenář jistě poznal, že jde o soubor s indexem MYISAM tabulky MySQL database.
Číslo 429'258 ponechám raději bez komentáře.
Je nutné doplnit, že se jedná o ext3 o velikosti 80GB s 4kB bloky, je namountován jako /var a je zaplněn z 80%, tj 16GB volného místa. FS byl vytvořen 1.března 2008 (je tedy mladý). Stroj slouží jako běžný domácí server.
Co říci závěrem? Těším se na ext4 u něhož vývojáři počítají s online defragmentací. Program shake
(který je asi nejlepším pokusem o defrag in userspace) považuji za aprílový žertík a spíše je to doklad žalostné situace linuxových FS a jejich nástrojů.
Tiskni Sdílej:
Nechám si poradit jak optimalizovat index.V PostgreSQL příkazem
REINDEX
. U MySQL nevím.
Každopádně defragmentace by ten soubor alepoň spojila dohromady.A následující zápisy ho zase budou fragmentovat. Myslím, že na udržení málo fragmentovaných souborů pro databázi musí databáze a souborový systém spolupracovat – ale nevidím důvod, co by jim v tom bránilo. Podle mne pokud bude databáze alokovat diskový prostor napřed a používat řídké soubory (tj. oznámí souborovému systému, že bude potřebovat pravděpodobně velký soubor, ale fyzicky si zatím vezme jenom část), a souborový systém bude takové soubory alokovat tak, že (pokud je místo na disku) vynechá na disku místo pro celý takový soubor, pak by k fragmentaci nemělo docházet. Samozřejmě pokud databáze zvětšuje soubor po malých blocích s tím, že souborový systém se s tím nějak vyrovná, bude soubor fragmentovaný, protože tenhle způsob využití je netypický a obecný souborový systém pro něj asi nemůže být optimalizován.
malloc
u. Tedy program by sdělil operačnímu systému délku vytvářeného souboru, OS by jej alokoval jak nejlépe by to šlo a program by pak zapisoval data.
A fragmentaci by asi nejvíc pomohlo mít databázové soubory na vyhrazeném oddílu – pak by se do těch databázových souborů nemotaly fragmenty jiných souborů a fragmentace by měla zůstat na nízké úrovni.
Abych nakonec nedopadl jako pan Ponkrác akorát bych měl oddíly dle aplikací. /www /mysql /squid
LVM samozřejmně používám .
... LV Write Access read/write LV Status available # open 1 LV Size 96.19 GB Current LE 3078 Segments 3 Allocation inherit Read ahead sectors 0 ...
Jo jo, chtělo by to nějakej LVM defrag .
Wau. Je to hodně mladá funkce, takže asi nebude moc rozšířená, ale je to krok správným směrem. Díky.
No jestli chceš mám tu jiné pikantní příklady souborů, které byly zapsány pouze jednou na oddíl o 50% zaplnění.Budu hádat - velké soubory, které se zapsaly naráz, ale stejně jsou fragmentované...
Nechávat mezi soubory volné místo (tj "fragmenovat" prázdné místo) je velmi elegantní způsob jak zabránit fragmentování samotných souborů. Zásadní chybou interního defragu ve Windows je snaha vše naplácat na jednu hromadu. Jediný defrag do Windows který umí spojit soubory a nechat místo místem je Raxco Pefrect Disk. Pak je celý proces stejně rychlý jako třeba xfs_fsr
. Velký soubor je pak samozřejmně fragmentovaný (protože je nacpán do těch volných míst), ale většinou to není nijak tragické. Pár seeků navíc při čtení mnoha GB souborů průměr rychlosti čtení moc neovlivní.
Btw. kde se to nechá stáhnout?
filefrag
? Na Fedoře jej mám v balíčku e2fsprogs
.
Na Fedoře jej mám v balíčku e2fsprogsAha, ono je to přímo v utilitách pro ext3, tak tam mě nenapadlo hledat. Jdu se stydět do kouta.
Nechám si poradit jak optimalizovat index. Tabulka byla optimalizována mnohokrát. Každopádně defragmentace by ten soubor alepoň spojila dohromady.Ten soubor by spojila dohromady...a to by se projevilo přesně jak, hm? Copak k indexovým stránkám se přistupuje sekvenčně? Není to takhle náhodou B-strom? Ten se traverzuje značně nesekvenčním způsobem. Krom toho u slušně nakonfigurovaného serveru se stejně minimálně ty indexy vejdou do paměti. "Optimalizovaná tabulka". Chm. Všichni machři na Internetu s tím slovem obratně žonglují, ale ještě z nich dostat vysvětlení, co tím vlastně mají na mysli. Každopádně to nejlepší, co můžeš udělat, je hodit databázi na raw partition a porovnat výkon se současným stavem. Tím by se ukázalo, kolik ten ext3 vlastně užírá, poněvadž jedině u raw partition má server jistotu, že má bloky skutečně za sebou, a může se tomu i přizpůsobit. (BTW, ten filefrag mi nepřijde nijak extra použitelný. Kdysi jsem si napsal podobnou toolu, ač velice základní, ale určitě by k ní šel dodělat mnohem hezčí výstup. Hmm. Zamyslím se nad tím. )
Defragmentuje tuším prostým kopírováním, metodou pokus-omyl.
Ano, tohle dělá i shake. Problém je, že to nelze použít pro soubory otevřené pro zápis.
reiserfs nemá podobný nástroj vůbechm, myslel jsem si, že pro reiserfs existuje placený repacker, ale když se to pokouším googlit, tak dostávám samé nesmysly o tom, že repacker bude v reiser4, a když se to pokusím vyloučit, tak dostávám informace typu, že "ještě" nemá z mailinglistů starých sedm let apod. :-/