Secure erase may false-fail due to Linux page cache

[Guilherme G. Piccoli]

Currently, secure erase performs a data check to be sure the procedure works. This data check is basically write a buffer to disk, do secure erase and read the disk, comparing the read data with the first buffer written (it should differ when secure erase is successful).

But...Linux has page cache, and Python default primitives for read/write files rely on regular read/write syscalls, going through the page cache and potentially showing false failures of secure erase (that despite working, may fail due to the data check reading the buffer from the page cache instead of the just secure-erased disk).

We could argue that hdparm (when doing secure erase) should either reset the device or clear the page cache, and this argument seems valid. But, in the short-term, let's fix MAAS by using direct I/O to perform the data check.

[Igor Gnip (igorgnip)]

Note - this was tested on real bare metal hardware and I can confirm that the fix results secure operation consistently succeeding as opposed to prviously (falsely) detecting failure to secure erase and then proceeding with a falback method. Speedup should be noticable as secure erasing an SSD drive takes under 15 seconds whilst zero-filling one takes 15-30 minutes.
For usual magnetic media, at least not both procedures are done so speedup should be at least 50%.

[Guilherme G. Piccoli (gpiccoli)]

Great feedback Igor, thank you! I'm glad that MAAS CI tests "passed", so we are just waiting on some review from MAAS team.
Cheers,

Guilherme

[Guilherme G. Piccoli (gpiccoli)]

Fix was just merged in MAAS master branch: https://git.launchpad.net/maas/commit/?id=527d185c