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

Re: growisofs should have a method for padding



Hi,

me: > > 
> > So let us assume for now that DVDs are still safe
> > in that aspect.
Volker: >
> ... I have had the end-of-recording read errors on DVDs
James: >
> ... I see the problem frequently

Ok. Let's consider padding necessary on CD as well as DVD.
Anybody able to tell a record breaking number of missing
tail bytes ? (My worst experience was when 128 kB did not
suffice to protect the tail.)


James: >
> 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.

I use Andy's growisofs without kernel patch. It
formats virgin DVD+RW automatically.


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

I learned that my DVD writer (/dev/sr0 via ide-scsi)
reads zeros from never written addresses while my
DVD-ROM drive (/dev/hdd) stops at the beginning of
the virgin part of the DVD+RW but it returns all
bytes which have been written.
In some way it looks that your drives neither
stop nor dream of zeros but stumble.

I am not so sure that this is the genuine read-ahead-bug.
Maybe you found a new subspecies or even parallel
evolution. :))


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

One could have the backup script or some cron job
re-enable it via  hdparm -d1 . To my experience
one may change DMA settings even while the drive
is in use for writing. The backup was ok, afterwards.


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

I would hurry to test this.
Random access might produce other results or
other bugs than sequential access.
Nevertheless the failure of tar to read the
entire archive is an alarming sign.


> This problem might be worked around by writing zeroes to the entire media 
> before using it.

I would prescribe my users to use such prepared
media as long as the verification problem cannot
be solved otherwise (for example by writing some
pad data behind the archives end).


Have a nice day :)

Thomas



Reply to: