> > > I've got problems with Andy Polyakov's DVD+RW kernel patch. I'm > > > using kernel 2.4.21 and I've got a NEC 1300 drive. > > > > As the web page mentions, even though DVD+RW is specified to provide > > for true random write, not all units actually live up to this promise. > > Unfortunately:-( In addition to 2nd generation Ricoh-based units (as > > mentioned on the page), SONY units were also reported to work > > reliably, but that's about it... At least among a number of reports > > from NEC users, not a single one was a success story:-( > > Well, NEC say it is supposed to do packet writing.
I for one am reluctant to refer to DVD+RW recording strategy as "packet writing" and the kernel patch in question can't be classified as "packet writing." Generally speaking from programmer's point of view "packet writing" is pretty much about coalescing I/O requests and making them strictly aligned in certain manner (e.g. at 32K boundaries). It's also about performing of aligned_read-update-aligned_write whenever you want to write a chunk smaller than alignment unit. Stuff like that. The patch in question does nothing of that sort. It merely permits the kernel to issue WRITE commands whenever DVD+RW media is mounted, totally relying on unit firmware to perform the magic [such as read-update-write cycles] upon most likely non aligned I/O requests. > Does anyone know whether this works under Windows? Windows programs commonly apply packet writing strategy (coalescing and requests' alignment as discussed above) to DVD+RW, even though it's *not* *formally* necessary. This however naturally makes life for firmware a *lot* easier and that's what NEC must be "ceritfying" their units for. One can say that this is not compliant "certification" as DVD+RW is supposed to provide for *true* random write access and one would be actually right stating this. But as long as NEC hides behind "designed exclusively for Windows" and keep providing Windows software which applies packet writing strategy even to DVD+RW, you won't be able to make them address the problem "by the root" so to say. Unfortunately:-( > It's odd that a sequential write to /dev/scd0 fails, but a sequential > write to /dev/raw/raw1 works OK. No, it's not. > How to the SCSI commands that they send to the device differ? I/O to /dev/scdN passes through common block buffer, which is free to rearrange the requests. E.g. I could observe 'dd of=/dev/scdN obs=32k' being rearranged as a serie of 126K requests. At the beginning of recording that is. As recording is normally way slower than dd, block buffer starts starving for memory at some point and starts fragmenting at 2K, 4K, 14K, 31K, literally whatever chunksizes, which by the way can even appear in *non-ascending* order. This is confusing for your firmware. /dev/raw/rawM on the other hand maintains the strict order and fragmentation implied by the writing program. In other words 'dd of=/dev/raw/rawM obs=32k' results in serie of 32K requests in strictly asceding order. Something your firmware can bear with. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
