On Tue, Jul 29, 2008 at 06:03:34PM -0600, dann frazier wrote:
> > What size is the partition being erased?
>
> ~73G
blockdev-wipe writes random data in blocks of 65536 bytes.
So we have (70 * 2^30) / 2^16 = 70 * 2^14 blocks to write.
With the progress bar divided into 100 steps, this means that we have
one update every 11468 written blocks. Does not really sound reactive
to me! :)
> > After having a look at the source code, it's possible that, for a very
> > large partition, the progress would be updated rarely enough to give you
> > the impression that the Cancel button do not work, as its result would
> > not be checked often enough.
>
> That sounds plausible, and after adding some debug statments, I
> believe that your theory is correct. A kill does occur after the next
> iteration of the while loop after I click cancel. There's just a long
> time between iterations.
> […]
> Consider that a user might click cancel with no immediate result, then
> a minute or two later they are moved along to the next step (creating
> a password for the volume). They maybe led to believe that the wipe
> completed successfully, even though their cancel attempt did
> eventually succeed and cause the rest of the disk to not be cleared.
Let's make it more reactive then and leave the current code as is, IMHO.
> > A possible fix in that case would be to divide the progress into more
> > steps than the current 100. But a deeper investigation would be
> > required before that.
>
> I wonder if there's a way to split the cancel checking and the
> progress checking? […]
It might be, but I am not inclined to do this kind of changes that tend
to breaks in very subtle way just before Lenny.
Dividing the progress bar in 65536 parts will give us an abitility to
cancel it every 1114112 written bytes, and should make it reactive
enough.
Cheers,
--
Jérémy Bobbio .''`.
lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
Attachment:
signature.asc
Description: Digital signature