abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 17:30 | Zajímavý článek

Mozilla.cz informuje, že webový prohlížeč Firefox bude od verze 53 obsahovat integrovaný prohlížeč dat ve formátu JSON. Firefox kromě strukturovaného prohlížení nabídne také možnost filtrace a uložení na disk. Dle plánu by měl Firefox 53 vyjít 18. 4. 2017.

Ladislav Hagara | Komentářů: 0
dnes 11:00 | Komunita

Členové a příznivci spolku OpenAlt se pravidelně schází v Praze a Brně. Fotky z pražských srazů za uplynulý rok si můžete prohlédnout na stránkách spolku. Příští sraz se koná už zítra 19. ledna – tentokrát je tématem ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. Také budete mít příležitost si prohlédnout pražský hackerspace Brmlab.

xkucf03 | Komentářů: 0
včera 21:55 | Komunita

Nadace pro svobodný software (FSF) oznámila aktualizaci seznamu prioritních oblastí (changelog), na které by se měli vývojáři a příznivci svobodného softwaru zaměřit. Jsou to například svobodný operační systém pro chytré telefony, hlasová a video komunikace nebo softwarový inteligentní osobní asistent.

Ladislav Hagara | Komentářů: 7
včera 16:44 | Nová verze

Byla vydána verze 2.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu.

Ladislav Hagara | Komentářů: 0
včera 15:33 | Komunita

V australském Hobartu probíhá tento týden konference linux.conf.au 2017. Na programu je celá řada zajímavých přednášek. Sledovat je lze online.

Ladislav Hagara | Komentářů: 0
včera 10:20 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje bitmapovým (rastrovým) grafickým editorům ve Fedoře. V prvním dílu se věnuje editorům MyPaint, MtPaint, Pinta, XPaint, Krita a GIMP. V pokračování pak editorům GNU Paint (gpaint), GrafX2, KolourPaint, KIconEdit a Tux Paint.

Ladislav Hagara | Komentářů: 1
16.1. 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
16.1. 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 2
16.1. 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 7
15.1. 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (3%)
 (75%)
 (3%)
 (10%)
Celkem 314 hlasů
 Komentářů: 24, poslední včera 10:14
    Rozcestník
    Reklama

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

    28.9.2008 00:47 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Děsivě pomalý zápis DVD+RW s UDF
    Přečteno: 955×

    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

    28.9.2008 01:01 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

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

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    28.9.2008 01:24 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

    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.
    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    28.9.2008 20:09 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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.
    28.9.2008 20:44 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

    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.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    28.9.2008 21:14 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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é.
    28.9.2008 22:43 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

    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.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    28.9.2008 23:34 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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.
    29.9.2008 08:46 Vinicius
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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 avatar 29.9.2008 06:46 Selmi | skóre: 17 | Košice
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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 avatar 29.9.2008 12:16 BigWrigley | skóre: 32
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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.
    Linux is like a wigwam - no windows, no gates and Apache inside.
    BigWrigley avatar 29.9.2008 12:17 BigWrigley | skóre: 32
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    ...nejak mi vypadlo "na mechanice"
    Linux is like a wigwam - no windows, no gates and Apache inside.
    29.9.2008 21:43 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

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

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    29.9.2008 22:45 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

    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. :-D 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 avatar 2.10.2008 15:15 BigWrigley | skóre: 32
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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... :-D BTW: na RAMkach mam celkem zajimave zkusenosti s novymi FS typu reiser4 a btrfs. Chovaji se totiz ve srovnani s UDF naprosto fantasticky.
    Linux is like a wigwam - no windows, no gates and Apache inside.
    2.10.2008 16:54 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

    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.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    29.9.2008 15:16 x22
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF
    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.
    29.9.2008 21:53 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Děsivě pomalý zápis DVD+RW s UDF

    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ě? :-D Já asi zanechám experimentů s DVD+RW a zkusím ještě DVD-RAM, než mě ten vypalovací elán definitivně přejde.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    30.9.2008 09:55 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Bug v kernelu

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

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.