Portál AbcLinuxu, 10. května 2025 16:40
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.
29.9.2008 06:46
Selmi | skóre: 17
| Košice
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.)
BTW: na RAMkach mam celkem zajimave zkusenosti s novymi FS typu reiser4 a btrfs. Chovaji se totiz ve srovnani s UDF naprosto fantasticky.
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:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
29.9.2008 12:16