Re: growisofs should have a method for padding
On Friday 13 May 2005 20:07, James Finnall wrote:
> On Friday 13 May 2005 14:34, scdbackup@gmx.net 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
Reply to: