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?But back to the problem. You've got to elaborate on "some i/o errors."Ok:Apr 14 13:00:34 donald kernel: end_request: I/O error, dev 16:00 (hdc), sector 12028 Apr 14 13:00:34 donald kernel: end_request: I/O error, dev 16:00 (hdc), sector 12030
Isn't there a way to make ide-cd module log more verbose information such as sense codes? I used to use ide-scsi, which logs more... If there is no way, then you can as well modify growisofs to perform READ operations instead of WRITEs. Just to catch the exact sense code! To be specific. Download latest dvd+rw-tools, open growisofs_mmc.cpp, locate line with // WRITE(10) [should be line #376] and replace 0x2A with 0x28. Then locate closest cmd.transport [should be line #410] and replace WRITE with READ. Then compile and run ./growisofs -poor-man -Z /dev/dvd=/dev/zero. Question is when does it stop and with which error code.
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. ... - 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.Can I patch linux for doing so
What kind of question is that? Of course you can! The question might as well have been if there is a similar patch available... Well, that I don't know... But it should be trivial...
or which (unix-like) os do you recommend for doing so?
I don't have any recommendations.
^^ This byte comprises a number of various bits. Two most significant bits are AWRE (Automatic Write Relocation Enable) and ARRE (Automatic Read Relocation Enable). 80 (which is hex) means that AWRE is on, but *not* ARRE! Meaning that there is a chance that your unit signals "this better be relocated" on some block and you should be able to "recover" your media if you engage ARRE. But it's crucial to find the exact error code. If you can't make kernel log more verbose code, modify growisofs as suggested above...- 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.dvd+rw-mediainfo /dev/hdc verbose INQUIRY: [HL-DT-ST][DVDRAM GSA-4081B][A100] MODE SENSE[#3Fh]: 01: 80 13 00 00 00 00 03 00 00 00
GET [CURRENT] CONFIGURATION: ... 0024: 80 00 00 00
For reference. The above means that defect management control is engaged.
^^ This might be interesting to look at [it's Spare Area utilization statistics]. An idea for next dvd+rw-mediainfo update:-)READ DVD STRUCTURE[#FF]: ... STRUCTURE#0a 40:16
READ FORMAT CAPACITIES:
For reference.
^^^^^^^ This must be capacity with minimal Supplementary Spare Area.formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792
^^^^^^^ This must be capacity without Supplementart Spare Area.00h(800): 2295072*2048=4700307456
^^^^^^^ This must be capacity with maximal possible Supplementary Spare Area. Might be an idea for next dvd+rw-format update:-) A.01h(800): 2217248*2048=4540923904