rsync - Dec 2009 - How do I make rsync ignore unreadable files (damaged sectors)?

Lately I've working on a backup script that utilize rsync together with
MySQL logging. Everything has been working just fine until now when I needed
to generate some errors for my error handling code.

So I took a CD (which I scratched with a needle) and mounted it to the file
system. There after I started the backup job which went on forever and never
got completed. It seems that rsync refused to understand that the file it
tried to copy was located on damaged sectors on the CD, and there fore was
unreadable.

So what I want is to make rsync skip a file after a couple of unsuccessful
attempts to read it. I have searched Google for an answer and looked at the
rsync manual but I couldn't find anything useful.

Thanks for your assistance.

/Tomas Gustavsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20091222/07c8e143/attachment.html>

On Tue 22 Dec 2009, Tomas Gustavsson wrote:
> 
> So I took a CD (which I scratched with a needle) and mounted it to the file
> system. There after I started the backup job which went on forever and
never
> got completed. It seems that rsync refused to understand that the file it
> tried to copy was located on damaged sectors on the CD, and there fore was
> unreadable.
I suspect that this is more down to the OS and the CDROM drive both
trying very hard to read the damaged data. You would have to do a strace
or similar to determine whether rsync is actually getting IO errors from
the OS or not.


Paul

Did I understand this correctly?
rsync skips a file as soon as it receives an I/O error from the OS?

Then the solution would be to write a script in such a manner:
1) Set OS I/O timeout/attempts to your maximum tolerance.
2) rsync --your --options
3) Set OS I/O timeout/attempts back to the default OS values.

On which OS can you modify the maximum timeout/attempts for I/O errors?
And how? And for what kind of devices?
Curious for: Mac OS X, Windows, Linux.

Am 22.12.2009 um 12:35 schrieb Paul Slootman:
> I suspect that this is more down to the OS and the CDROM drive both
> trying very hard to read the damaged data. You would have to do a  
> strace
> or similar to determine whether rsync is actually getting IO errors  
> from
> the OS or not.
>
> On Tue 22 Dec 2009, Tomas Gustavsson wrote:
>>
>
>> So I took a CD (which I scratched with a needle) and mounted it to  
>> the file
>> system. There after I started the backup job which went on forever  
>> and never
>> got completed. It seems that rsync refused to understand that the  
>> file it
>> tried to copy was located on damaged sectors on the CD, and there  
>> fore was
>> unreadable.

>> On 22.12.2009 16:39, Stefan Nowak wrote:
>>
>> The only low-budget test ideas I have:
>>
>> The CD scratching a la Tomas Gustavsson seems the only easily  
>> achievable
>> solution. But then it is not sure whether the OS does the reading  
>> retries
>> or whether the optical disk drive itself retries reading.
>
> On 22.12.2009 at 19:10 Matthias Schniedermeyer wrote:
>
> Get some Old, cheap and as small as possible USB-Sticks.
>
> Especially when they are small you should be able to reach the
> overwrite-limits relativly fast (Which may still be counted in days)
>
> Depending in model you should be able to get some interesting errors,
> maybe even total breakdowns.
> ;-)
Your suggestion, to make the destination volume (USB stick) full, will  
result in write errors! If you mean "size-limit" by
"overwrite-limit"
What we wanted was, how to provoke read errors, and Paul Slootman  
already offered a solution for that: hdparm --make-bad-sector.
Or did you mean to write a small testfile on a flash drive, then  
overwrite it multiple times (more often than the specified "overwrite  
limit") by an automated loop, as long until you get the first write  
error, and hence you can expect a bad sector at this file, and then  
use it as a broken test source?

Now some German talk: Servas Oida! Gruesse aus Wean (Wien) ;-) Stefan  
Nowak