martijnvanbrummelen / nwipe

nwipe secure disk eraser
GNU General Public License v2.0
682 stars 77 forks source link

finetuning for 0.35 #515

Closed ggruber closed 9 months ago

ggruber commented 9 months ago

if we are about to finetune: I suggest adding the output of a "." for every disk on startup. (you may see this in eraseHDD). Helps the user/admin if there are many and among them slow disks. Similar when shutting down: there was a significant delay when I finished a 6 SAS disks wipe this morning when the PDF files are written. There is a writing "Waiting for wipe thread to cancel for /dev/sd"x but then happens nothing. I know that then the PDF reports are written. I suggest to printf "Writing nwipe PDF reports" and then again print a dot for every file written.

If anyone would support these ideas: they are easy to implement (and we could possibly re-release 0.35 polished edition;-) )

PartialVolume commented 9 months ago

I think the window for fine tuning has passed. It would only be a show stopper bug to re-release 0.35.

Any further changes would be applied to the master and would appear in 0.36.

Similar when shutting down: there was a significant delay when I finished a 6 SAS disks wipe this morning when the PDF files are written.

The delays are not caused by the PDF creation, each PDF will be created in a fraction of a second. When you see on the GUI a disc say 100% complete, linux's disc cache will still be full and a final fdatasync is issued to flush the cache to disk. Say you are wiping 6 drives and all have finished but one that is at 90% and you have 10GB CPU memory, the disc cache will expand to use most of the available memory. So although the GUI says 100% complete the wipe thread is still waiting for the cache to be flushed. So you could have 10GB of disc cache waiting to be flushed at a speed of 100MB/sec, this could take about 100 seconds before the cache has flushed, hence why you get "Waiting for wipe thread to cancel for /dev/sd" and then nothing appears to be happening, at least on screen, in the background the O.S is flushing the disc.

If you have a significant amount of CPU memory, say 64GB then this delay can be substantial. i.e 640 seconds ( 10 minutes !)

This wouldn't be a problem with dual buffered direct I/O that avoided the use of the O.S's disc cache mechanism. Another reason why I prefer a direct I/O option be implemented in nwipe.

For people wiping a laptop with 4GB RAM and a single drive the delay may be less than 40 seconds.

Also the disk flush starts as soon as the GUI reports 100% complete not when you exit nwipe with the spacebar so most people that have walked away from the system and came back to find it's finished hit the spacebar to exit and there is barely any delay because the cache has been flushed already.

ggruber commented 9 months ago

we could add the number of drives being wiped behind the throughput in the overview, e.g. 1870 MB/s on 42 disks

disputable, if the number should change if drives get finished.