>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 _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
