[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

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

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]