[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
other backups?

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 linux-kernel issues?

Quoting specification:

"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 some operations.

- 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 Linear Replacement.

- 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 writing DVD-RAM. - 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.

Reply to: