Backing up audit data with growisofs

Question

We've had a problem occur when writing to DVD+Rs and DVD-Rs using growisofs on Redhat Enterprise Linux 5.0. What we’re trying to do is backup audit data that we've stored, which is basically one .zip file for each day's worth of audit data. The .zip files are relatively small, generally only a few megabytes each. We receive the following error message from growisofs when writing to a DVD+R or DVD-R:

:-( unable to pread64(2) primary volume descriptor: Input/output error
you most likely want to use -Z option.

growisofs also exits with an exit code of 150. According to a Debian mailing list post I read (link no longer working) growisofs returns errno+128, so this appears to correspond with errno=22, which is EINVAL (Invalid argument).

The primary volume descriptor is definitely there as we have already initialized the DVD with -Z. The first thing we do is growisofs -Z, followed by one growisofs -M command per file. The error usually happens on the second file we write--i.e., the DVD is initialized with -Z, we write one .zip file successfully, and then the second .zip file yields this error message.

A simple workaround is to physically eject the DVD and then re-insert it at which point the DVD works again and we are able to write the rest of the files. That's less than ideal, though. The error is not consistent but it is quite frequent and ejecting seems to always fix the problem.

Here are the commands we use to write to the DVD:

growisofs -Z /dev/dvd -rJ -use-the-force-luke=notray blank.iso

for each FILE:
    growisofs -M /dev/dvd -rJ -use-the-force-luke=notray "$FILE"

Here's sample output from dvd+rw-mediainfo /dev/dvd, if it helps:

INQUIRY:                [TEAC    ][DV-W28EC        ][1.0B]
GET [CURRENT] CONFIGURATION:
 Mounted Media:         1Bh, DVD+R
 Media ID:              RITEK/F16
 Current Write Speed:   8.0x1385=11080KB/s
 Write Speed #0:        8.0x1385=11080KB/s
 Write Speed #1:        6.0x1385=8310KB/s
 Write Speed #2:        4.0x1385=5540KB/s
 Write Speed #3:        2.4x1385=3324KB/s
 Speed Descriptor#0:    00/2295103 [email protected]=11080KB/s [email protected]=11080KB/s
 Speed Descriptor#1:    00/2295103 [email protected]=8310KB/s [email protected]=8310KB/s
 Speed Descriptor#2:    00/2295103 [email protected]=5540KB/s [email protected]=5540KB/s
 Speed Descriptor#3:    00/2295103 [email protected]=3324KB/s [email protected]=3324KB/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:       00h, DVD-ROM book [revision 0]
 Legacy lead-out at:    2295104*2KB=4700372992
READ DISC INFORMATION:
 Disc status:           appendable
 Number of Sessions:    21
 State of Last Session: empty
 "Next" Track:          21
 Number of Tracks:      21

Any ideas on what is causing this problem or how to fix it?

Answer 1

CD/DVD burner handling on Linux has always been flaky, without much developer or vendor interest in fixing the problems. DVD+R's got the worst of it.

If your drive is the type that can un-eject, do an "eject disk" and "eject -t disk" after each writing operation. I never dared user growisofs to grow an ISO filesystem, just to write to DVD+Rs when dvdrecord/cdrecord stopped working on DVD+R. Both with growisofs and cdrecord, I usually had to eject / uneject to get a freshly written disk to work.

Answer 2

I was having this problem with Ubuntu 9.04 and growisofs 7.1 and it turned out to be the file that I was trying to back up was not accessible. I would suggest checking to be sure that $FILE exists and has proper permissions before passing it to growisofs. I assume that the message ":-( unable to pread64(2) primary volume descriptor: Input/output error you most likely want to use -Z option." is probably a bug since the problem was with the source file and not the destination media.

Answer 3

Short answer - Strace it. I'm not denying that any of the above responses are correct in their cases - but I had it happen because I did not have write permissions to the DVD drive. Then it happened again because I didn't have permission to access the underlying SCSI Generic device (/dev/sg1). So in short - it looks like this is a very generic error that could have many root causes.