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í.
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.
ČTENÍ dd bs=1M count=1024 if=test.test of=/dev/null ZÁPIS dd bs=1M count=1024 if=/dev/zero of=test.test conv=fdatasync ROZDĚLENÍ DISKŮ (jednotky = sektory) Disk /dev/sda: 1500.3 GB, 1500300828160 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930275055 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x76334c22 Device Boot Start End Blocks Id System /dev/sda1 2048 19531775 9764864 fd Linux raid autodetect /dev/sda2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sdb: 2000.4 GB, 2000397852160 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907027055 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xd9cd6c6d Device Boot Start End Blocks Id System /dev/sdb1 2048 19531775 9764864 fd Linux raid autodetect /dev/sdb2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00006673 Device Boot Start End Blocks Id System /dev/sdc1 2048 19531775 9764864 fd Linux raid autodetect /dev/sdc2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0xe27ff672 Device Boot Start End Blocks Id System /dev/sdd1 2048 19531775 9764864 fd Linux raid autodetect /dev/sdd2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sde: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0xb765ccd8 Device Boot Start End Blocks Id System /dev/sde1 64 19530608 9765272+ 83 Linux /dev/sde2 19530616 2930277160 1455373272+ 83 LinuxPoslední disk má trochu jiné rozdělení, nicméně to by nemělo vadit, stejné problémy se vyskytovaly i v degradované konfiguraci pole (jen nemám otestovanou rychlost). Zajímavé také je, že resync (právě po přidání tohoto posledního disku) běžel ze začátku 1.5-3MB/s a ráno, když jsem se vzbudil, tak jel 35MB/s... Opět nechápu proč. Dodám ještě, že server není téměř vůbec vytížený, jde vlastně jen o souborový server pro několik uživatelů.
Řešení dotazu:
Třeba jeden disk "pomalu" umírá - v lepšim případě špatný sektory, v horšim....dělaly mi to zatím dva disky, když se dostanou hlavičky do jednoho konkrétního místa tak disk zacvaká, zastaví se, během chvilky se znova roztočí a snaží se pokračovat...někdy se ani nezastaví a hlavičky jen kmitaj třeba pět minut na jednom místě než se odtrhnou a pokračujou dál (Windows umře hned, tučňák se snaží pokračovat, ale jak se disk chytne tak rychle všechno uložit, protože do minuty příjde kernel panic).
Kupodivu S.M.A.R.T. mi na to říkal že je všechno v pořádku, nakonec mi to jeden člověk pořádně projel, našel DVA špatný sektory a bylo jasno - i když nechápu, brácha má na stejnym disku vadných sektorů údajně desetitisíce a nic jako zastavování nebo ty zátuhy se u něj neprojevuje. Mimochodem byly to disky Western Digital Green, už nikdy víc.
(nic lepšího mě nenapadlo)
Zdá se, že v poli byly dva pomalu umírající disky - jeden víc umírající a jeden míň umírající. Víc umírající jsem vyhodil z pole a proto začal to samé (= vytížení na 100%) dělat druhý, zřejmě míň umírající disk, který byl přecejen trošku rychlejší než více umírající... bohužel mi nedošlo, že v poli můžou být dva vadné disky naráz a proto jsem celou dobu hledal chybu někde jinde, včetně špatného nastavení mdadm a bůhvíčeho ještě :) Díky za nakopnutí. Po vykopnutí z pole i tohoto disku se výkon RAID 1 zlepšil ze 17MB/s na 90MB/s.když jsem to zpozoroval vytížení disku na 100%, zkoušel jsem disk vyřadit z pole a během chvíle začal to samé dělat jiný disk, takže to není tímhle :(
Pokud jsou to disky WD tak bych se trošku bál, co jsem prostřídal několik WD disků, tak bezproblémově funguje jen historický 40GB, ostatní (dva 500GB) umřely až podezřele rychle, po půlroce jsem jeden posílal na reklamaci, když mi přišel zpátky tak vydržel jen pár dalších měsíců a odešel znova....takže jsem ho poslal na reklamaci (kus za kus) a prodal nový disk jen kousek pod cenou Koupil jsem dva samsungy 500GB, systém na RAID0 (až umře disk, tak to poznám), data na kterých moc nezáleží (muzika, panoramatické fotky, výtvory v GIMPu a swap) taky na RAID0 a jen to na čem opravdu záleží mám na RAID1
Snad se moje zkušenost hodila, nikdy bych nevěřil že se disk může zaseknout v jedné pozici a jen tam "tikat" i přes pět minut než se odtrhne a bude pokračovat ve čtení/zápisu.
Tiskni Sdílej: