Re: [Dvdrtools-users] Re: [Fwd: Re: Is my MSI DR8-A2 broken?]

[Bryan J. Smith]

Svante Signell <address@hidden> wrote:
> No I did not, The file size is 4685914112 bytes which is
> less than 4.7 GB. 

Is that the size of the ISO file?
Or is that the size cdrecord reports?

Remember, an ISO file is an archive.

When expanded onto media, instead of files being packed
byte-for-byte next to each other, they are now put into 2KiB
blocks.
So the size is then _larger_ when recorded.

That's why cdrecord will report the size to be bigger when
recorded.
There is also overhead outside of the ISO9660 Yellow Book
(data) track.

You're pushing awfully close to that "raw" capacity.  ;->

> Thanks for the info, it gives a good background on this
> issue! So, in conclusion I should use dvd+rw-tools for
> DVD+R/RW and have a choice of
> dvd+rw-tools,dvdrecord,cdrceord+DVDpatch,cdrecord-Pro for
> DVD-R/RW.

Exactly.  You can also use the kernel packet/rewrite support
for DVD-RW and DVD+RW as of kernel 2.6 (and DVD-RAM going
back to 2.0/2.2).  Although you'll need to format DVD-RW/+RW
with UDF first.

> Additionally, my NEC ND4551A suports DVD-RAM. Which tool to
> use for that media?

Use the built-in kernel support (since 2.2).  Just mount it
directly ...

  mount -o rw /dev/hdc /mnt/dvdram -t udf

This assumes, of course, your kernel has UDF filesystem
support.  Most 2.6 kernels do.

You should _never_ have to format DVD-RAM, as it is
pre-formatted CLV with UDF filesystem.

> Do you say that if I write a file located in /dev/hdc and
> the writer is at /dev/hdd, i should disable DMA for both
> drives?

Not exactly.

What I said was you should _never_ put DMA devices in a
master/slave relationship, but 1 device per channel.

I also said that it is legacy EIDE PIO modes that were
designed for master/slave, and those modes are _very_slow_. 
PIO mode 4, 16MBps, is the fastest, typical (PIO mode 5,
22MBps, was rarely implemented).  It will also _kill_ your
CPU.

> Are you really sure here?

Yes, very sure!  Been all over the ATA specs over the last
few years.

> This is a trap many people can fall in.

Unfortunately, ATA allows this relationship for old PIO
compatibility.

> If this is true, a _dangerous_ warning should be
> issued whenever an DVD burner is installed on an IDE drive.

The Best Common Practice (BCP) is that only *1* ATA device be
used per channel.  With Serial ATA, which always uses DMA,
the ATA specification disallows any master/slave
relationship.

> This would then apply to all burners installed in PC, Linux
> Windows, etc computers.

Yes!  ATA in DMA mode means the Integrated Drive Electronics
(IDE) of the drive is talking directly to the system memory. 
That's why you should _never_ have more than 1 device per
channel.  Because it requires a major change in the bus
operation, which often results in bus resets.

> What about the case of copying files from one hard disk to
> another, for example /dev/hda to /dev/hdb? In that case the
> file transfers should never finish.

Huh?  How did you get that logic?  I never even suggested
such.

/dev/hda takes control of the bus, negotitates DMA and writes
to memory.  /dev/hdb then takes control of the bus,
negotiates DMA and reads from memory.  Just because the
operation requires a major context switch and cannot occur
simultaneously doesn't mean it doesn't finish.

It just doesn't happen simultaneously.  If you have a
real-time process like DVD recording, then that's a serious
issue.

Matters are drastically complicated when a master and slave
run the bus differently, let alone don't implement the full
ATA command set in their IDE (which is very typical). 
Sometimes some ATA devices don't "disconnect" from the bus
correctly either.  Remember, ATA is not SCSI.

> Since I've never heard about this problem, it is hard to
> believe! 

Heard about what problem?
There is no "problem" -- there are only ATA specifications.
ATA DMA was _never_ designed for master/slave.
Only PIO mode was, commonly marketed by Western Digital as
EIDE.



-- 
Bryan J. Smith     Professional, Technical Annoyance                      
address@hidden      http://thebs413.blogspot.com
----------------------------------------------------
*** Speed doesn't kill, difference in speed does ***