Bruno Haible <[EMAIL PROTECTED]> writes: > Suggestion: Could shred, when encountering this error on a block device file, > print the error message but nevertheless continue with the remaining passes? > That would be more useful than the current behaviour.
'shred' already attempts to do just that -- it attempts to deduce the size by looking at the errno value after failed 'write'. But apparently this isn't working for your kernel and/or driver, so we need to figure out how to modify 'shred' to handle your case. What's the size of the partition in question, exactly? > 03:06: rw=0, want=4200968, (=0x401a08), limit=4200966 > /usr/bin/shred: /dev/hda6: error writing at offset 4301787136: Input/output > error > ... > /usr/bin/shred: /dev/hda6: error writing at offset 4301787137: Input/output > error After reading through the 'shred' code, here's my guess as to what happens: First, 'shred' uses lseek (fd, 0, SEEK_END) to determine the size of the device. It gets the value 4,301,789,184 (this is 4,200,966 * 1024). Then, 'shred' writes a series of 12 KiB buffers. It writes 350,080 buffers successfully, for a total of 4,301,783,040 bytes. Subtracting this last value from the size 4,301,789,184, it gets 6 KiB, so it decides to write a 6 KiB buffer. But it gets a short write of 4 KiB, which means that the file offset is now 4,301,787,136 (the number in the diagnostic quoted above). It then tries to write the last 2 KiB but gets an I/O error, which it reports. At this point 'shred' is supposed to use lseek to skip around the "bad block" (which I suspect is not really a bad block, though I don't know what it is). So it lseeks to 4,301,787,136 + 512 = 4,301,787,648 and tries to write 2 KiB - 512 B = 1,536 bytes. This write reports that 1 byte (!) got written, so it then tries to write 1,535 bytes. This last write fails, so it reports a write error at offset 4,301,787,137. Since this offset is not a multiple of 512, dopass returns -1. > and stops after the first pass. That is because dopass returned -1. It normally doesn't do that, even for an attempt to write past the end of the device, but if it gets really weird results it will. > The only option that helps is to use the --size option with a value of the > limit mentioned above (4200966), minus 2, times 1024. This suggests that the operating system is lying about the device size, and is claiming that it is 4,200,966 * 1024 = 4,301,789,184 bytes, whereas it is "really" 2,048 bytes smaller. Had it not been for a write returning 1, which sounds quite bogus (and perhaps my theory is wrong...), things would have worked OK. Perhaps you can use 'strace' to check my guesses above? _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
