[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shred and odd partition sizes
From: |
Paul Eggert |
Subject: |
Re: shred and odd partition sizes |
Date: |
Wed, 23 Aug 2006 21:52:36 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
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?