Re: Packet writing on NEC1300
> > > 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.
Reply to: