Re: shred and odd partition sizes

[Paul Eggert]

Bruno Haible <address@hidden> 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?