Dotaz: Děsivě pomalý zápis DVD+RW s UDF

[Andrej]

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:

• DVD±R: 22
• DVD+RW: 8
• DVD-RW: 6
• DVD+R DL: 16
• DVD-R DL: 12
• DVD-RW DL: 2
• DVD-RAM: 12

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?

Odpovědi

[Andrej]

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...

[Andrej]

Fňuk.

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.

[petr_p]

A co jste si představoval. Já těmhle věcem moc nerozumím, ale z principu zápisu na DVD-RW je logické, že přepisování rozstroušených sektorů bude výkonostní propadák.

Mám takový dojem, že packet writing režim je pouhá emulace blokového zařízení s náhodným přístupem. Ve skutečnosti, se musí vždy dané sektory načíst, smazat, sjednotit původní data s novými, počkat než stopa vychladne a pak zapsat sjednocená data.

[Andrej]

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.

[petr_p]

Jen drobné upozornění: nepleťte si souborový systém UDF a packet-writing. Tak jako si mohu na CD klasickým SAO/TAO vypálit třeba obraz ext2 nebo jediný tar (neřeším zarovnání na sektor), tak si mohu pomocí packet-writingu zapisovat, co chci a kam chci.

O tom, co řeší UDF a co mechanika (např. ochranu před opotřebením), pomlčím, protože o tom nic nevím.

Rozhodně jsou vaše poznatky cenné.

[Andrej]

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.

[petr_p]

Díval jsem se na Wikipedii, tam se popisují tři režimy UDF, přičemž se tvrdí, že linux umí jen tzv. „plain build“, tj. že k médiu přistupuje jako k médiu s náhodným zápisem bez nějakých pokusů o ochranu před opotřebením na úrovni UDF.

V dokumentaci k jádru se zase píše, že je implementována emulace náhodného zápisu přes pktcdvd, která je, díky bufferování, efektivnější, než to, co se nachází ve firmwaru vypalovaček.

Podle dostupných voleb pro mount, se zdá, že jádru není možné říci, který režim UDF má použít. Takže asi tomu bude tak, že Linux umí jen režim „plain build“.

Vás by asi zajímal režim UDF „spared build“, který dle Wikipedie počítá počet zápisu na stejné místo, a po překročení jistého počtu daný sektor označí za opotřebovaný a přemapuje jej jinam. O tom, zda je snaha na médium zapisovat cyklicky a nepřepisovat stále stejné místo, Wikipedie mlčí.

Ale je tam odkaz na specifikaci UDF (PDF). Tak zkuste štěstí tam.

[Vinicius]

U DVD-RAM s realokovanými bloky to není tak zlé, zkoušel jsem takové na více mechanikách a OS a všechna data byla přečtena, ovšem asi tak 1/5 rychlostí, protože laserová hlava létala z jednoho konce kotoučku na druhý.

[Selmi]

to su presne moje skusenosti s dvdeam a linuxom - znicene media a nehorazne pomaly zapis, u mna naviac rychlost s casom stale klesala, takze ani zapis jedneho velkeho suboru nebol pouzitelny... ale nasiel som ludi co im to fungovalo, takze zrejme to zalezi od hw. (priklad http://kerneltrap.org/node/6600)

[BigWrigley]

Taky jsem myslel, ze jsem nekolik medii nenavratne znicil. Nebylo je mozne ani naformatovat, natoz vytvorit FS. U vsech pomohl dvd+rw-format -force Panasonic SW-9576.

[BigWrigley]

...nejak mi vypadlo "na mechanice"

[Andrej]

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...

[Andrej]

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.)

[BigWrigley]

Otazka je, jestli by Vam Panasonic s DVD+RW pomohl, sam jsem tato media nezkousel, resp. ne pro PacketWriting. A s cenou mate pravdu, byla totiz asi za 3.500 (umi media v cartridge, coz bylo pro me hlavni kriterium). Jinak tedy mate ale odvahu a trpelivost. 16000 souboru na DVD medium a cekat 7 hodin na unmount... BTW: na RAMkach mam celkem zajimave zkusenosti s novymi FS typu reiser4 a btrfs. Chovaji se totiz ve srovnani s UDF naprosto fantasticky.

[Andrej]

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.

[x22]

Ja som kedysi pouzival DVD-RAM s ext2, ale bez paketoveho zapisu (DVD-RAM a DVD+RW funguje aj bez neho). Bolo to celkom spolahlive, aj ked pomale. DVD+RW som skusal len raz, to je este pomalsie a uz si nepamatam, ci to vobec islo precitat.

Teraz mam externy disk.

[Andrej]

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.

[Andrej]

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é.