On Tue, 15 Jan 2019 18:19:26 +0200 Svjatoslav Agejenko <svjatos...@svjatoslav.eu> wrote:
   * What led up to the situation?

I choose to wipe disk space on BTRFS formatted
internal SSD or external flash drive. Same behavior in
both cases. Have not tested on other filesystems.

I chose 1 for number of passes.

I did not chose "Fast and insecure mode".

I did not chose "Last pass with zeros instead of random data".

Then I click button "Wipe".

   * What was the outcome of this action?

I see new dd process appear in the process list that looks like this:
 dd if=/dev/zero of=/media/.......... bs=8M conv=fdatasync


   * What outcome did you expect instead?


I did expect random data, not zero space fill.

What you are seeing is an artifact of libgsecuredelete's workaround for the underlying sfill tool ignorance of file system size limits and internal implementation [1]. Basically, what is happening is that large zero-filled files are created (to reduce the amount of free space), then the free space left (if any) is wiped with sfill, and finally the zero-filled files are deleted with srm using the options you selected.

This indeed adds an additional pass of zeroes on the free space, but the final result should still be what you expected (I'm not entirely sure for magnetic analysis, but I'd guess it should still be pretty close), albeit with an additional pass.

Unfortunately, something along those lines is required to support filling space larger than the FS's max file size, because of sfill limitations. Without this for example filling 5Gb on a FAT32 FS would fail, and actually leave about 1Gb untouched.

[1] https://git.tuxfamily.org/wipetools/libgsecuredelete.git/tree/gsd-sfill-helper.sh.in

Also I cannot cancel this operation. When I click cancel button
I get popup asking to either pause or cancel. I click cancel,
and popup window disappears but dd process continues in the background.

That should be looked into then, but a possible reason might be that filling might require root privileges but the controlling (user) process won't be able to affect root processes.

HTH,
Colomban

Reply via email to