Michael Schwarz wrote:
Update: (For those who've been waiting breathlessly). It hangs at a particular point in a particular file. In other words, it doesn't depend on the total number of bytes transfered. Rather, when it reaches a particular point in a particular file (12267520 bytes into a file that is 1073709056 bytes long) it hangs.
I have an odd thought, have you tried copying that same file to /dev/null or similar? The reason I ask is that if it were by any chance a sparse file, while the program is reading all those unwritten bytes odd things may happen. Sorry, I haven't seen this is years, but I do remember seeing a filesystem on the destination end running out of space because all those unwritten pages were now being "really written" as zeros.
Use of cp with the --sparse= flag may change the behavior if this is the case.
I begin to suspect that I have a "dead spot" in my USB hub. But what gets me if that is true is why does the write work? Do cp and dd not check to see if writes succeed? I know it isn't a particular flash drive because I've used two different sets of 7 USB drives and it seems to fail consistently no matter which. Nonetheless, I'm beginning to think I'm dealing with a hardware issue, not a kernel issue, just because it is so consistent. Thanks again for all the help.
-- bill davidsen <davidsen@xxxxxxx> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
