On Friday 13 May 2005 20:07, James Finnall wrote: > On Friday 13 May 2005 14:34, [EMAIL PROTECTED] wrote: > > Hi, > > > > > I would have expected that what was true of CDs would be true with > > > DVDs. > > > > So let us assume for now that DVDs are still safe > > in that aspect. At least no real problems have > > been reported. (Nevertheless i pad 300 kB) > > If you are interested in another two cents. I see the problem > frequently and in the beginning I thought it was defective hardware. > Until I found out about this kernel read-ahead issue. > > On many servers now I use DVD+RW media for backup purposes just like the > old tape drives, sequential in format using the tar command and written > using sdd with 32k blocks. If this part fails it is almost always media > related, like the customer inserted new media and I didn't know it and > it wasn't formatted. This operation requires Andy's kernel patch. > > After the backup process is complete a verification process is started. > If this error happens it will be near the end of the verification on the > media. It also has a side effect of taking the drive out of DMA mode > and after the failure the backups are a lot slower until the server is > rebooted. But the errors are reported like below. > > Starting Backup . . . > /usr/bin/sdd: Read �3496920 records + 0 bytes (total of 1790423040 bytes > = 1748460.00k). > /usr/bin/sdd: Wrote 54639 records + 12288 bytes (total of 1790423040 > bytes = 1748460.00k). > Starting Verification . . . > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: Too many errors, quitting > /bin/tar: Error is not recoverable: exiting now > Backup operation completed. > > The problem is more frequent on a new server where the customer is > adding data to the drives daily and rarely will be deleting anything. > The backup grows each night and more and more media is required to hold > it. Once the customer starts to delete information, the error becomes > less frequent because the media has stuff written past the new backup. > > This problem might be worked around by writing zeroes to the entire > media before using it. At least it would provide something for it to > read all the way to the end of the media. Since this is not an ISO > image it is just raw data written to the media. > > So far I have not had to use one these failures to reload the data back > on the server. But if I had to, I think that sdd with arguments > instructing how much data to read could be used again to just read the > tar data back to hard disk and then restore it normally. So I have not > used this error problem as a reason to stop using DVD+RW for backup > purposes. The backup itself is complete, it is only the verification > process that will produce this error. > > The best resolution I can think of would be to turn off read-ahead > operations on optical media. Or at least a config option on certain > devices that could be set from rc.local to disable read-ahead caching. > Even just an echo command into the /proc system like the command to turn > on packet forwarding would be sufficient. > > James
I just thought of another possible solution I need to test. The write operation using sdd with 32k byte aligned structures requires the use of a raw device to bypass the VM system and file buffering issues. I usually bind the drive to /dev/raw/raw1 for this. If I attempted to verify using the same raw device to read the backup back for verification it might not use the read-ahead that other devices use. I will need to test this but it might be possible for the raw device to bypass the kernel problem. James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
