Názory k článku Smažíme v Linuxu (3)

mam CD-RW, na ktorom su uz chybne bloky. daju sa pri napalovani nejako preskocit? resp. ako vytvorit image, aby bloky XXXX - YYYYY neobsahovali uzitocne data? kludne tam moze byt vypis /dev/null, ale ako prinutit mkisofs, aby takyto subor ulozil na presnu poziciu?

Pokud použijete Mt. Rainier, pak bez problémů.

Na klasické vypalování vůbec. U paketového je jistá šance, pokud použijete něco ve stylu badblocks (nikdy jsem nezkoušel).

Tak depresivni odsouzeni multisession jsem snad jeste nevidel :-) Autor asi nema dulezita data, ktera inkrementalne vypaluje prave na multisession cd. Ale to je kazdeho vec.
Nicmene pro mazani cdrw je mozne tez pouzit parametr pro rychle mazani blank=fast (smaze jen tabulku obsahu, nemaze cele cd).
Faktem je, ze vypalovani multisession cd neni v linuxu zas tak jednoduche a je co dohanet (v porovnani s ms win).

Dulezita data se pali na pasku :)

Ze nie je jednoduche? Spravil som si niekolkoriadkovy skript v bashi na palenie. Pred vypalovanim sa ma opyta par otazociek, a mimochodom aj to ci xem aj multisession -- automaticky sa importne predosla session. Ak niekto xe, poslem :)

cdrecord blank=all trvá zbytečně dlouho. Pokud chci použít CD od začátku, stačí cdrecord blank=fast. To vymaže jen nutné věci (aby ho vypalovačka viděla jako prázdné), zbytek nechá být.

Pálení multisession je zbytečně komplikovné - IMHO by mělo stačit zabudovat do CDRECORD nějaký přepočet - vždyť se ty data "jenom" posunou o pár bloků dál ... (ale je fakt že to asi skoro nikdo nepoužívá a ti co ano tak si už zvykli).


Mimochodem doufám že v dalším díle bude postup jak vypálit na jedno CD větší množství dat - řekněme tak 2GB by byly optimální :)
Docel aby mě zajímalo, jestli se to dá nějak zautomatizovat - zatím se musí :
a) vytvořit zpakovaný strom
b) .. z něj sesmolit ISO

Takže je potřeba 2x tolik místa :-\

Informace o predchozi session musi byt uz v .iso image. Pokud tam neni, CDRecord s tim nic nenadela. Ja jsem si (mimo jine) na pripalovani multisession sveho casu splichtil nasledujici skriptik: http://puk.penguin.cz/sbanka/clanek.php3?id=89

<I>Informace o predchozi session musi byt uz v .iso image<I>

Jde o to JAKÁ informace. Pokud vím, musí se při sestavování nové image zadat jedno jediné číslo - a to je (celková) velikost dřívější(ch) session(s).
Nevím co s tím mkisofs dělá, ale IMHO jde jen to, že se jednotlivé struktury (kořenový adresář apod) o tento údaj relativně posunou. Takže by IMHO neměl být problém o tento pevný offset příslušné údaje posunout přímo v cdrecord během pálení. Ale je to jenom takový nápad, který asi nikdo realizovat nebude (což je škoda).

Jestli se adresare v ISO8990 odkazuji na konkretni bloky, pak by musel cdrecord predelavat tyhle odkazy, coz asi neni nejlepsi napad - bylo by potreba vstupni data parsovat.

Co roury, nezkoušel jste? Uznávám trochu drsný způsob, ale možná i funkční :-)

V dobe technologii typu burnproof a rychlych kompu to az tak drsne byt nemusi.

Roura nejde použít (nebo aspoň nevím jak) - data se před vytvářením image musí "předžvýkat" programem mkzftree a jeho výsledek se musí někam uložit ..

No jo, ale tohle jde pro "klasické" CD.
Pro "komprimované" je ještě předtím potřeba udělat jeden krok :

mkzftree <intree> <outtree>

.. a až pak se dá na <outtree> poštvat mkisofs ..| cdrecord ..

BTW parametr "-o -" u mkisofs není potřeba - defaultní nastavení je cpát výsledek do stdout.

Nazdarek vespolek,

nesetkali jste se nekdo s tim, ze vypalovacka, ktera udajne podporuje overburning (Yamaha 8424 SCSI) overburnit odmita? Konkretne vyhlasi SCSI errory, jakmile palena delka prekroci 700MB ...

Cdrecord 2.0 (i686-pc-linux-gnu), option -overburn samozrejmosti.

Dik za odpoved, KJ

Asi spatne.
Mam starsi vypalovacku od Mitsumi, ktera by to mela taky zvladat. Kdyz do ni strcim 99minutove CDR, hlasi delku 19 minut, pri zapisu do 20. minuty hodi SCSI chybu ...

Kdy uz bude firmware open-source ?

je az legracni, jak hodne se tento clanek podoba tomu, ktery jsem napsal bezmala pred tremi mesici pro abclinuxu.cz:
http://www.abclinuxu.cz/clanky/ViewRelation?relationId=17682