Re: DVD-Ram diagnostics
I was told, that DVD-Ram is very secure because of its structure. Today a
nearly four months old DVD-Ram failed. (Maxell, non-cartrigde version). My
LG-4081B throw some i/o errors when I tried to dd the dvd-ram with random
data in order to encrypt it.
I could not see any scratches, dust or any fingerprints on the dvd.
What might have gone wrong? How can I detect it? How do I proctect my
DVD-RAM is no more secure than DVD-RW if both are not inside a cartridge.
Even without cartridge DVD-RAM *is* more secure because a) DVD-RAM media
can sustain *way* more overwrite cycles and b) DVD-RAM logical unit is
*required* to implement defect management system.
If you use "Formatted" DVD (non RAM) media, you of course need to make sure
that you are using Mt. Fuji (DVD-RW)
Mt. Fuji does *not* define defect management for DVD-RW [at logical unit
firmware level], so there is nothing anybody can "make sure," when it
comes to comparing DVD-RW and DVD-RAM from this viewpoint.
or Mt. Rainier (DVD+RW), otherwise
DVD-RAM is still better.
DVD+MRW vs. DVD-RAM is a trade-off. DVD-RAM is more durable (because it
sustains more overwrites), while DVD+MRW can be accessed in legacy
DVD-ROM units (because defect list and spare area are accessible for
host software). But unfortunately DVD+MRW is not something one can "make
sure" as of now, as there're no actual DVD+MRW firmware implementations
on the market.
ok. But what may have gone wrong?
But back to the problem. You've got to elaborate on "some i/o errors."
Is it a media-error or do I do have to upgrade firmware or are there any known
"The DVD-RAM format is designed to enable the following Linear
Replacement methods, with some consideration for issues of real-time
data recording, where for example the reassignments are disabled during
- When recording data with verification by the WRITE AND VERIFY (10)
command, the logical unit has an opportunity to evaluate the written
data and if the data is found defective, the logical unit may perform a
- For data recorded without verification, the logical unit has an
opportunity to evaluate the written data when the host attempts to read
the data from that LBA and if the data is found defective but
correctable by ECC, the logical unit may perform the Linear Replacement
operation, if read reassignment is enabled."
As you read the quote you ask yourself following questions.
- Was data recorded in "real-time mode, where reassignments are
disabled?" No. "Real-time recording" implies that writes are performed
with WRITE(12) command with "Streaming" bit set. Linux kernel never uses it.
- But was data recorded "with verification by the WRITE AND VERIFY (10)
command?" No. Linux kernel doesn't use WRITE AND VERYFY command when
- But is "read reassignment enabled?" I don't know. How to tell? There
is an ARRE, Automatic Read Reallocation Enable bit in page 01. You can
dump the pages with 'dvd+rw-mediainfo /dev/dvd verbose'. Send the output
to the list, so we can see if ARRE is on.
However! Even if ARRE is on, there is yet another possibility for things
to *appear* broken. Specfication mentions that unit raises a warning
condition when Supplementary Spare Aread is about to be exhausted and
needs to be grown. If Linux kernel does not interpret it as warning (at
the very least it could ignore it and log a message at console), it
shall appear as I/O error to application. As for growing spare area.
Note that it implies that filesystem can be shrunk. As it's problematic
to shrink file systems, it might actually make sense to maximize the
spare area prior creating file system. Note that I don't know if
there're Linux apps readily available that will let you grow spare area
or manipulate ARRE bit. The above suggestions has rather theoretical
character as they are not based on personal experience (don't have
DVD-RAM capable unit).
Bottom line. "some I/O erors" is not good enough to tell what's going
on. Examine kernel log to find out the exact error code. A.