Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Byla vydána (Mastodon, 𝕏) nová verze 3.0.4 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Byla vydána nová stabilní verze 7.4 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 136. Přehled novinek i s náhledy v příspěvku na blogu.
/dev/sda: WDC WD15EADS-00P8B0: – WesternDigital /dev/sdb: ST31500341AS: – SeagateVypadá to, že čtení brzdí WesternDigital.
# dd if=/dev/md0 bs=1M count=1024 | pv > /dev/null 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 10,3183 s, 104 MB/s 1GB 0:00:10 [99,2MB/s] # dd if=/dev/sda1 bs=1M count=1024 | pv > /dev/null 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 158,554 s, 6,8 MB/s 1GB 0:02:38 [6,46MB/s] # dd if=/dev/sdb1 bs=1M count=1024 | pv > /dev/null 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 9,09674 s, 118 MB/s 1GB 0:00:09 [ 113MB/s]Vím, že to není žádné úžasné měření, ale pro představu snad postačí. Použil jsem
pv
, abych sledoval průtok průběžně – u sda
se často rychlost dostávala na nulu, přenos se úplně zastavil. A průměrná rychlost tohoto disku byla nakonec horší než rychlost kdejaké flešky.
Předtím jsem prováděl několik opakovaných měření pomocí hdparm -t
a ty tak špatně nedopadly (buffered disk reads):
/dev/md0: Timing buffered disk reads: 362 MB in 3.00 seconds = 120.55 MB/sec Timing buffered disk reads: 268 MB in 3.01 seconds = 89.16 MB/sec Timing buffered disk reads: 272 MB in 3.00 seconds = 90.59 MB/sec Timing buffered disk reads: 368 MB in 3.00 seconds = 122.50 MB/sec Timing buffered disk reads: 240 MB in 3.01 seconds = 79.80 MB/sec /dev/sda1: Timing buffered disk reads: 266 MB in 3.01 seconds = 88.30 MB/sec Timing buffered disk reads: 266 MB in 3.02 seconds = 87.97 MB/sec Timing buffered disk reads: 248 MB in 3.01 seconds = 82.26 MB/sec Timing buffered disk reads: 274 MB in 3.01 seconds = 90.99 MB/sec Timing buffered disk reads: 274 MB in 3.01 seconds = 91.01 MB/sec /dev/sdb1: Timing buffered disk reads: 366 MB in 3.01 seconds = 121.72 MB/sec Timing buffered disk reads: 362 MB in 3.00 seconds = 120.57 MB/sec Timing buffered disk reads: 368 MB in 3.01 seconds = 122.43 MB/sec Timing buffered disk reads: 362 MB in 3.00 seconds = 120.48 MB/sec Timing buffered disk reads: 366 MB in 3.01 seconds = 121.54 MB/secPo chvíli jsem pustil čtení znova, tentokrát 10 GB a dopadlo to úplně jinak:
# dd if=/dev/sda1 bs=1M count=10240 | pv > /dev/null 10GB 0:01:39 [ 102MB/s] 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 10 737 418 240 bajtů (11 GB) zkopírováno, 99,9046 s, 107 MB/s # dd if=/dev/md0 bs=1M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 10 737 418 240 bajtů (11 GB) zkopírováno, 92,5676 s, 116 MB/s 10GB 0:01:32 [ 111MB/s] # dd if=/dev/sdb1 bs=1M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 10 737 418 240 bajtů (11 GB) zkopírováno, 88,7582 s, 121 MB/s 10GB 0:01:28 [ 115MB/s]Najednou to vypadá OK. Občas zkouším systém sledovat pomocí iotopu, ale nevšiml jsem si žádného procesu, který by nějak výrazně zatěžoval disk. Pak jsem ale pustil čtení ještě jednou, tentokrát 20 GB a opět špatné:
# dd if=/dev/sda1 bs=2M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 21 474 836 480 bajtů (21 GB) zkopírováno, 1 205,7 s, 17,8 MB/s 20GB 0:20:05 [ 17MB/s]Průběžně jsem sledoval
iotop
a proces dd
byl většinou na prvním místě – nikdo ho nepředbíhal, leda výjimečně načítala něco databáze nebo webový server. Rychlost, kterou dd
četl, byla ale velice často nulová (bez zjevné příčiny – disk nezatěžoval nikdo jiný). Hned nato jsem spustil stejné čtení z druhého disku.
# dd if=/dev/sdb1 bs=2M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 21 474 836 480 bajtů (21 GB) zkopírováno, 174,596 s, 123 MB/s 20GB 0:02:54 [ 117MB/s]Proces
dd
četl z tohoto disku (podle pv
i iotop
u) rychlostí kolem 100 MB/s – ale hlavně plynule, rychlost nekolísala ani nepadala na 0 MB/s.
Jelikož věštecké koule jsou celkem drahá věc, zkouším to nejdřív tady, třeba vás něco napadne. Řešením samozřejmě může být ten WD vyhodit a dát tam nějaký jiný, ale třeba se najde ekonomičtější řešení.
Tiskni
Sdílej:
Když jsem vydělil údaje ve specifikaci (kapacita ÷ počet sektorů), tak mi vychází 512.
A ukazuje mi to i hdparm -I /dev/sda
:
Logical/Physical Sector size: 512 bytes
A v popisu jumperů ten Advanced Format chybí (u jiných disků je).
Už mi pomalu to WD (a celé Green IT) začíná lézt krkem, nejdřív problémy s Load_Cycle_Count
a teď tohle.
dd if=/dev/sda bs=1M count=10240 skip=10240 | pv > /dev/nullNejdřív to šlo docela dobře (normální rychlost), ale kolem šestého GB se to nějak pokazilo a rychlost čtení je 0 B/s – jen občas tam blikne 1 nebo 8 MB/s. Čtení prakticky stojí. Ale podle
iotop
u mu nikdo nebrání.
-H
, ale před nějakým časem i testy a vypadalo to OK (pomalé to bylo už tehdy).
Tomu disku všechno moc trvá – jak ten smartctl -H
, tak třeba i zjištění teploty přes hddtemp
– zatímco ten Seagate odpovídá okamžitě.
# ./seeker /dev/sda Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/sda [1430799MB], wait 30 seconds............... Results: 0 seeks/second, 2142.86 ms random access time # ./seeker /dev/sdb Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/sdb [1430799MB], wait 30 seconds............................. Results: 63 seeks/second, 15.63 ms random access timeTak mi připadá, že mám v počítači místo jednoho disku kus šrotu (WD).
Tady si stáhni utilitku Data Lifeguard Diagnostic. Tam se mrkni, jak to s tou velikostí sektoru opravdu je.
Podle všeho WD ignoruje problém s WD15EADS-00P8B0.
Hoď ten disk prodejci na hlavu a vezmi si něco jinýho. Nevypadá to totiž, že by WD chtěl tenhle problém nějak řešit.
Za svůj život jsem pravda měl jenom dva pevný disky značky WD, ale oba dva dost rychle umřely.
Na druhou stranu s disky od Seagate mám dobrou zkušenost.
zero
, ale náhodná data. Beztak je potřeba ten disk přepsat několikrát (7x?), aby z něj zaručeně nešlo nic obnovit. Hlavně, že jsem tu o tom nedávno psal. A teď si to „užívám“ prakticky.
No reklamovat i tak, že se tam udělá jeden oddíl NTFS/FAT32, a další 3 Linux XFS/EXT4 a spolehlivě z toho žádný chytrák nic nedostane.Komiku.. Viz wikibooks - Jak postupovat při záchraně dat. Postupy lze uplatnit na libovolný souborový systém, pokud není šifrovaný.
Hardware_ECC_Recovered
a Raw_Read_Error_Rate
(musí se shodovat). Kdežto u WD musí být hodnota Raw_Read_Error_Rate
nulová!
Moje zkušenost je taková, že obecně jsou disky Seagate spolehlivější bez ohledu na řadu, zatímco u WD opravdu velmi záleží na tom o jakou řadu jde. A jelikož v tom jejich značkování se prase vyzná, preferuji disky od Seagate.
md0
nebo sda
. Na dvou dalších počítačích mám stejnou konfiguraci (LVM nad SW RAIDem) a tam jsem s výkonem spokojený.