Standard Matter (Wikipedie, GitHub), původně Project Connected Home over IP (CHIP), pro propojení IoT a domácí automatizaci byl vydán ve verzi 1.4.
Fedora Linux je aktuálně k dispozici v 5 edicích: Workstation, Server, IoT, Cloud a CoreOS. Pro desktopové nasazení je určena edice Workstation, což je prostředí GNOME. Vývojářům a uživatelům KDE Plasma se dlouhodobě nelíbí, že jejich prostředí je schováno mezi spiny, tj. alternativními desktopy. Prosadili si, že s následující verzí Fedora Linuxu KDE Plasma povýší ze spinu na edici a bude tak na úrovni Workstation.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch OTA-6 Focal, tj. šesté stabilní vydání založené na Ubuntu 20.04 Focal Fossa.
Byla vydána nová verze 8.0 (𝕏) frameworku pro vývoj webových aplikací Ruby on Rails (Wikipedie). Přehled novinek v příspěvku na blogu, v poznámkách k vydání a na GitHubu.
Byla vydána verze R14.1.3 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnes v 17:00 má na YouTube online premiéru krátký film Project Gold od Blender Studia představující možnosti rozšíření Blenderu pro "malířský vzhled".
Byl představen oficiální Raspberry Pi USB 3 Hub. Cena je 12 dolarů.
Na YouTube byly zveřejněny sestříhané videozáznamy přednášek z letošního OpenAltu. Dostupné jsou také přímo z programu po kliknutí na přednášku.
Co přesně se děje, když se pomocí curlu připojujeme ke google.com? Proč to psát do terminálu, když si to můžeme pustit jako videoklip curl -v https://google.com na YouTube. 😂
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.11.
Ahoj, po zjištění, že potíže s UDF se naštěstí týkají pouze CD-RW, mám tentokrát hardwarový dotaz. Koupil jsem si externí vypalovačku Samsung. Udávané rychlosti zápisu jsou:
Rychlosti jsou uvedeny v násobcích 1350 kB/s, jak bývá zvykem.
Problém je jednoduchý: Při zápisu na DVD+RW s UDF dosahuji rychlosti 250 kB/s. To je (mírně řečeno) hodně nepříjemné.
Tedy jednoduchá otázka: Co bych mohl mít špatně? Snad něco z tohoto...?
# sdparm --all --long /dev/sr0 /dev/sr0: TSSTcorp CDDVDW SE-S224Q TS00 [cd/dvd] Read write error recovery [rw] mode page: AWRE 0 [cha: y, def: 0] Automatic write reallocation enabled ARRE 0 [cha: n, def: 0] Automatic read reallocation enabled TB 0 [cha: n, def: 0] Transfer block RC 0 [cha: n, def: 0] Read continuous EER 0 [cha: n, def: 0] Enable early recovery PER 0 [cha: y, def: 0] Post error DTE 0 [cha: n, def: 0] Data terminate on error DCR 0 [cha: y, def: 0] Disable correction RRC 128 [cha: y, def:128] Read retry count COR_S 0 [cha: n, def: 0] Correction span (obsolete) HOC 0 [cha: n, def: 0] Head offset count (obsolete) DSOC 0 [cha: n, def: 0] Data strobe offset count (obsolete) EMCDR 0 [cha: n, def: 0] Enhanced media certification and defect reporting WRC 0 [cha: n, def: 0] Write retry count ERTL 0 [cha: n, def: 0] Error reporting threshold length (blocks) Write parameters (MMC) [wp] mode page: BUFE 0 [cha: y, def: 0] Buffer underrun free recording enable LS_V 0 [cha: n, def: 0] Link size valid TST_W 0 [cha: y, def: 0] Test write WR_T 0 [cha: y, def: 0] Write type MULTI_S 0 [cha: y, def: 3] Multi session FP 1 [cha: y, def: 0] Fixed packet type COPY 0 [cha: y, def: 0] Serial copy management system (SCMS) enable TRACK_M 7 [cha: y, def: 5] Track mode DBT 10 [cha: y, def: 8] Data block type LINK_S 0 [cha: n, def: 0] Link size IAC 0 [cha: y, def: 0] Initiator application code SESS_F 32 [cha: y, def: 0] Session format PACK_S 32 [cha: y, def: 0] Packet size APL 150 [cha: y, def:150] Audio pause length (blocks) Protocol specific logical unit [pl] mode page: LUPID 0 [cha: n, def: 0] Logical unit's (transport) protocol identifier Power condition [po] mode page: IDLE 1 [cha: n, def: 1] Idle timer active STANDBY 1 [cha: n, def: 1] Standby timer active ICT 2780 [cha: n, def:2780] Idle condition timer (100 ms) SCT 6000 [cha: n, def:6000] Standby condition timer (100 ms) Informational exceptions control [ie] mode page: PERF 0 [cha: n, def: 0] Performance (impact of ie operations) EBF 0 [cha: n, def: 0] Enable background function EWASC 0 [cha: n, def: 0] Enable warning DEXCPT 0 [cha: n, def: 0] Disable exceptions TEST 0 [cha: n, def: 0] Test (simulate device failure) EBACKERR 0 [cha: n, def: 0] Enable background (scan + self test) error reporting LOGERR 0 [cha: n, def: 0] Log informational exception errors MRIE 0 [cha: n, def: 0] Method of reporting informational exceptions INTT 0 [cha: n, def: 0] Interval timer (100 ms) REPC 0 [cha: n, def: 0] Report count (or Test flag number [SSC-3]) Timeout and protect (MMC) [tp] mode page: G3E 0 [cha: n, def: 0] Group 3 timeout capability enable TMOE 0 [cha: n, def: 0] Timeout enable DISP 0 [cha: n, def: 0] Disable (unavailable) until power cycle SWPP 0 [cha: n, def: 0] Software write protect until power cycle G1MT 6 [cha: n, def: 6] Group 1 minimum timeout (sec) G2MT 0 [cha: n, def: 0] Group 2 minimum timeout (sec) CD/DVD (MM) capabilities and mechanical status (MMC) [cms] mode page: D_RAM_R 1 [cha: n, def: 1] DVD-RAM read D_R_R 1 [cha: n, def: 1] DVD-R read D_ROM_R 1 [cha: n, def: 1] DVD-ROM read METH2 1 [cha: n, def: 1] Method 2 CD_RW_R 1 [cha: n, def: 1] CD-RW read CD_R_R 1 [cha: n, def: 1] CD-R read D_RAM_W 1 [cha: n, def: 1] DVD-RAM write D_R_W 1 [cha: n, def: 1] DVD-R write TST_WR 1 [cha: n, def: 1] Test write CD_RW_W 1 [cha: n, def: 1] CD-RW write CD_R_W 1 [cha: n, def: 1] CD-R write BUF 1 [cha: n, def: 1] Buffer underrun free recording MULT_S 1 [cha: n, def: 1] Multi session M2F2 1 [cha: n, def: 1] Mode 2 form 2 M2F1 1 [cha: n, def: 1] Mode 2 form 1 DP_2 0 [cha: n, def: 0] Digital port 2 DP_1 0 [cha: n, def: 0] Digital port 1 COMP 0 [cha: n, def: 0] Composite AUDIO_P 1 [cha: n, def: 1] Audio play RBC 0 [cha: n, def: 0] Read bar code UPC 1 [cha: n, def: 1] Uniform product code ISRC 1 [cha: n, def: 1] International standard recording code C2PS 1 [cha: n, def: 1] C 2 pointers supported RW_DC 1 [cha: n, def: 1] R-W de-interleaved and corrected RW_S 1 [cha: n, def: 1] R-W supported CDDA_SA 1 [cha: n, def: 1] CD-DA stream accurate CDDA_CS 1 [cha: n, def: 1] CD-DA commands supported LMT 1 [cha: n, def: 1] Loading mechanism type EJECT 1 [cha: n, def: 1] Eject (individual or magazine) PJ 0 [cha: n, def: 0] Prevent jumper LS 1 [cha: n, def: 0] Lock state LOCK 1 [cha: n, def: 1] Lock (supported) RWILI 1 [cha: n, def: 1] R-W in lead in SCC 0 [cha: n, def: 0] Side change capable SSS 0 [cha: n, def: 0] Software slot selection CSDP 0 [cha: n, def: 0] Changer supports disc present SCM 1 [cha: n, def: 1] Separate channel mute SVL 1 [cha: n, def: 1] Separate volume levels MRSS 16620 [cha: n, def:8467] Maximum read speed supported (kBps) (obs) NVLS 256 [cha: n, def:256] Number of volume levels supported BSS 2048 [cha: n, def:2048] Buffer size supported (1024 bytes) LENGTH 1 [cha: n, def: 1] Length (bit length of IEC958 words) LSBF 0 [cha: n, def: 0] LSB (least significant bit) first RCK 0 [cha: n, def: 0] High on LRCK indicates left channel BCKF 0 [cha: n, def: 0] BCK signal falling edge CMRS 1 [cha: n, def: 1] Copy management revision supported RCS 0 [cha: y, def: 0] Rotation control selected CWSS 5540 [cha: n, def: 0] Current write speed selected
Poslední řádka výpisu je zajímavá. Zvolená rychlost zápisu (je-li v kB/s) přibližně odpovídá čtyřnásobné rychlosti. To je jistě správné, protože médium DVD+RW, na které vypaluji, má toto omezení. Jenže proč je pak skutečná rychlost nějakých 250 kB/s? Pochopil bych, kdyby se dosahovalo například poloviny slibované rychlosti, ale tohle by měl i hlemýžď dávno vypálené!
Připomínám, že se jedná o externí vypalovačku. Tedy nejspíš není v mé moci nějak ovlivňovat použití cache a další parametry typické pro IDE. Write caching mám vypnutý, protože jeho použití se nedoporučuje. (Zatím neumí detekovat vadné médium.) Co bych měl tedy zkusit nastavit?
BTW, nešlo by to udělat tak, že by se celý UDF filesystém (první záloha) připravil předem a pak vypálil velkou rychlostí (bez packet writingu) a další zálohy by se pak dělaly jen pomocí rsync, tedy po relativně malých částech?
Představoval jsem si, že můj server bude na DVD zálohovat důležitá data každých 24 hodin. Jenže teď to vypadá asi tak, že jeden jediný zápis bude trvat déle než 24 hodin...
Existuje tedy možnost vytvořit nějaký obraz DVD s UDF filesystémem, pak ho (rychle) vypálit a po vypálení mít možnost ho normálně namountovat jako UDF?
To samozřejmě neřeší můj problém, ale jako workaround to ujde...
The big problem at the moment is performance. Copying a lot of small files onto a packet-written CDRW or DVD is very slow. If you've got enough patience, you'll find that it does work, but it is certainly not usable. Copying a few large files is fine, though.
Nepředstavoval jsem si bůhvíco. Ale i přesto jsem si od něčeho takového sliboval trochu víc. Právě teď jsem třeba zjistil, že souborový systém UDF buď žádný wear-levelling nedělá, nebo ho provádí pokoutním způsobem na úrovni souborů... Ať už je pravda jakákoliv, je to velké zklamání.
Zapsal jsem na DVD cca 3 GB dat v jednom souboru. Pak jsem tentýž soubor přepsal nějakými cca 4 GB dat. Tedy je jasné, že se oba soubory nemohly vejít na jedno médium. Zároveň ale žádný z nich nezabíral médium celé. Čekal jsem, že se při přepisu použije zbývající část média a když dojde prostor, začne se psát zase od začátku. Ničeho takového jsem se ovšem nedočkal. Po úspěšném přepsání a kontrole dat jsem zjistil, že kolem obvodu média je povážlivě tlustý nepopsaný kruh. Tedy je naprosto zjevné, že se soubor začal přepisovat od začátku.
Možná, že wear-levelling se týká jen nově vytvářených souborů, zatímco přepsání souboru se děje na místě. Je-li tomu tak, je to špatně. Například při zálohování se přece dá očekávat, že budu nahrazovat soubory. Pak je opotřebení povrchu média silně nerovnoměrné. Zatímco u DVD-RAM umí tahle mechanika (údajně) realokaci špatných bloků, podobně jako pevný disk, u DVD+RW nic takového není. (A v případě DVD-RAM si raději ani netroufám odhadovat, jak je médium s realokovanými bloky čitelné a přenositelné...)
Když jsem se dozvěděl, že spousta malých souborů tomu nesvědčí, jal jsem se to vyzkoušet. Zápis několika tisíc souborů trval cca 5 hodin, ale ani jeden ze dvou pokusů nebyl úspěšný. Médium bylo pokaždé zničeno a k selhání došlo zpravidla až po ukončení kopírování, případně při odmountování. Důvodem jsou s největší pravděpodobností chyby v kernelu. V logu jsem našel spoustu backtrace, které se mají ohlásit na bugzille...
Aspoň z toho mám jedno poučení: Už vím, proč se nikde nepoužívá packet writing pro zálohování. Důvody jsou vlastně dva: Zaprvé nevalná kvalita této technologie, která kromě ceny médií nenabízí žádné další výhody, a zadruhé špatná implementace plná chyb.
Já rozhodně nezaměňuji souborový systém a druh přístupu k médiu. UDF můžu mít klidně na DVD-RAM nebo na obyčejném pevném disku, to je jasná věc. Packet-writing a UDF samozřejmě nelze ztotožňovat, stejně jako nelze ztotožňovat například protokol IPv6 a WiFi. Jsou to různé technologie, které pracují každá na jiné „vrstvě“.
Jen tvrdím, že jsem od UDF čekal trochu jiné řešení přepisu volného místa. Například souborový systém LFS (Log-structured File System), vyvíjený nedávno na MFF UK, je navržený tak, že zapisuje „pořád dál“ a cyklicky přepisuje médium od začátku do konce. V rámci jednoho cyklu se nikdy nevrací k už zapsaným datům.
To jsem zkoušel, ale nepomohlo to. Médium se sice údajně naformátovalo, ale pokus o znovuvytvoření UDF nebo zápis čehokoliv jasně ukázal, že je definitivně passé. Pak už nefungovalo ani dvd+rw-mediainfo
.
Možná je to tím, že nemám mechaniku Panasonic...
Kdybych byl věděl, že mechaniky Panasonic jsou v některých (velmi podstatných) ohledech lepší než ostatní, asi bych byl při výběru typu uvažoval jinak... Já jsem se zaměřil hlavně na přístupovou dobu, kde Samsung vedl. Přiznávám, že jsem taky hodně koukal na cenu. Plánovaná životnost této mechaniky je totiž asi tak rok a půl, protože pak bych chtěl už nějaký nový domácí server a s ním související zařízení na BluRay.
Schválně jsem zkoušel několik beznadějně zkažených médií. Jediné, čeho jsem pomocí -force
dosáhl, bylo (ve dvou případech ze čtyř) správné rozpoznání média pomocí dvd+rw-mediainfo
. Pokus o znovuvytvoření UDF v jednom případě ze dvou selhal kvůli spoustě I/O errorů. Úspěšný případ trval extrémně dlouho (cca desetkrát déle než u zdravého média) a přestože nebyly hlášeny chyby, FS nešel namountovat. (Údajně vadný superblok and the like).
Faktem zůstává, že na DVD+RW médiu se toho snad nedá až tolik zničit, pokud není fyzicky poškrábané (což není) a pokud mechanika nemá nějaký hodně velký průser (což snad nemá, když je nová). Proto by měla existovat možnost, jak takové médium donutit ke spolupráci.
Mám ovšem nepříjemnou teorii: Ježto UDF v Linuxu neumí skutečný wear-levelling, (což už tu koneckonců bylo někde řečeno) médium v pohodě ustojí maximálně zapsání a přepsání několika velkých souborů. Velká spousta malých souborů způsobí, že některá místa na médiu jsou přepsaná řekněme k * N
krát, kde N
je počet souborů a k
přirozené číslo... To může znamenat průšvih.
To možná vysvětluje výsledky některých mých experimentů. Experimenty se stovkami souborů vždy fungovaly. Experiment s tisícem souborů taktéž fungoval. Unmount sice trval cca 3 hodiny, ale šlo to. Experiment s 16000 souborů vždy selhal. Kopírování proběhlo bez chyby. Unmount trval cca 7 hodin a většinou proběhl taktéž bez chyby. Médium pak většinou šlo normálně znovu přimountovat a číst... Jenže byla v tom zrada: Po vyjmutí z mechaniky a opětovném vložení už nešlo ani číst, ani mountovat. Ve dvou z celkem čtyř experimentů s 16000 souborů došlo k selhání zápisu během odmountování, cca ve třetí hodině tohoto procesu.
BTW, proč vlastně unmount trvá déle než kopírování? Je tomu tak (překvapivě) i v případě, kdy před odmountováním udělám sync a počkám, až mechanika přestane být aktivní...
Médium, které na některé své části zažilo k * 16000
přepisů, už nejspíš nezachrání ani Panasonic... Výše uvedenou teorii může potvrdit jedině DVD-RAM. U média dimenzovaného na 100000 přepisů by experiment s 16000 soubory měl vyjít. (Ale to ať si zkusí někdo jiný, já už toho mám plné zuby a nechci zničit ještě DVD-RAM. Už takhle jsem tím ztartil a * T
času, kde T
je maximální přípustná hodnota a a
výstup z vhodné Ackermannovy funkce.)
Momentálně to ovšem vypadá tak, že příčinou většiny mých problémů je bug v modulu ehci_hcd... Už jsem psal do mailing listu linux-usb, tak uvidím, zda mi na to někdo nějak odpoví. V Ubuntu takový bug řeší už 2 roky a nikdo neví, čím to je. V logu se objeví nenápadná hláška o resetování zařízení na USB. Pak už následuje jenom série chyb a nevyhnutelná katastrofa.
Další problém je v tom, že DVB-T tuner na USB 2.0 funguje v tomtéž řadiči normálně. Proto začínám mít obavy, zda nemám vadnou mechaniku. (Otázka je, jak bych při případné reklamaci něco takového vysvětloval...)
Reiser4 používám na mém notebooku a mám s ním (na pevném disku) velmi příjemné zkušenosti. Pokud jde o DVD-RAM, někdy to určitě vyzkouším. Jestli je rychlejší než UDF, určitě to stojí za pokus.
Napřed ale musím vyřešit otázku, co se to děje s mým řadičem a s komunikací přes USB. Pomalá a extrémně nepravidelná rychlost zápisu, kdy se třeba dvě minuty nic nezapisuje a pak se skokem přenese pár desítek megabytů, je bezesporu důsledkem toho problému s USB.
Stejně si ale myslím, že médium by se nemělo zničit tím, že se přeruší zápis. Jistě, bude na něm pak nějaké nečitelné místo a FS bude nekonzistentní. Ale když tam znovu vytvořím UDF a znovu zapíšu data, mělo by být zase všechno OK. Jenže není tomu tak. Jakmile se to médium jednou poničí (a ono se při prvním až druhém mountu zaručeně poničí), už je prostě passé a nedá se na něj rozumně psát. To je k vzteku.
Tak tohle ovšem vůbec nechápu... Jak je možné, že můžu přimountovat DVD+RW s UDF bez paketového zápisu a něco tam psát? Ono mi to prostě nějak funguje! Ale s CD-RW tohle nešlo.
Není to náhodou tak, že když mountuju /dev/pktcdvd/0
, řeší pakteový zápis kernel, zatímco při namountování /dev/sr0
to řeší firmware té mechaniky?
No ale teď jsem z toho jelen. Chvíli to funguje, chvíli ne, zničených médií plno, chyb v kernelu taky... Z toho by se jeden poblil.
BTW, fungovala ta optická média vůbec někdy někomu pořádně? Já asi zanechám experimentů s DVD+RW a zkusím ještě DVD-RAM, než mě ten vypalovací elán definitivně přejde.
Tak přece jen jsem měl aspoň v něčem pravdu, když se mi nepozdávala rychlost zápisu! A je to nepříjemná pravda. Tohle je i můj případ. Neřešitelný problém. Rada ohledně deaktivace suspend/resume vypadá sice nadějně, ale já možnosti typu selective suspend vůbec nemám zvolené.
Tiskni Sdílej: