Re: cp by blocks, with errors

[Bryan Henderson]

>The first one looks like it's solely a performance optimization for the
>case (common?) in which there are short reads.  Can you provide some
>data to justify adding this code?  Do you have a feel for how often
>cp gets short reads when block alignment would make a significant
>difference in performance?

I don't think the performance gains would justify the change.  The
main purpose of the change to block structured reads instead of
arbitrary byte stream reads (for me, that is) is to structure the
reads in a way more conducive to error recovery.  I.e. this was the
easiest way to write the error recovery code.


>Can you give an example showing why it'd be better to have this
>functionality in cp than in dd?

Dd is a low level copy tool.  It can't do things such as preserve
timestamps and permissions and copy a whole directory tree.  Also, I
think the idea of recovering a bad block by reading the good parts in
smaller chunks is a little too high level for dd.  I think the dd user
means to prescribe an actual sequence of read and write system calls
and doesn't want the program exercising any intelligence.

>Isn't it necessary sometimes to use lseek to get past an unreadable bit
>of media?

Yes.  That's what my cp patch does.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California