Direct disk access from python (simhdd)

Good afternoon, colleagues. Much time has passed since the first article was written. During this time, my library for disk access has learned to work with embedded SMART tests and their logs, as well as with the security mechanisms of modern drives.

This time I will talk about creating an application for testing hard disks based on this library.

I needed an application that can be run on a server with a hot-swap basket and test disks on it, replacing them as they pass the tests. The best solution for this seemed to me to start the process of testing each disk in a separate stream. Since I did not have the experience of multithreaded programming in python, I began to study the question. To create multi-threaded applications in python there is a threading module. Since threads are created within the same process, there is no problem accessing shared data. Everything looks very simple. Unfortunately, the problem was waiting for me. My library refused to work in multithreading mode. So my path lay to writing an application with several processes and all the charms of interprocess communication. Python has a multiprocessing module for this.

I saw the architecture of the application as follows: The main thread deals with user interaction. Displays a list of disks, accepts commands and displays the progress of tests. Each disk command is run in a separate process. To be sure that the test will be executed on the disk to which the command was given in the menu (for example, you can randomly rearrange the disks and forget to re-read it in the program) the serial number of the disk is made to execute the command. Before executing the command, the correspondence of the serial number of the transmitted command at startup to the serial number of the connected drive is checked. If the numbers do not match, the command is rejected with a sound signal. A useful feature to not accidentally run a destructive test on a disk connected to watch SMART.
')
To exchange data between the main process and the testing process, several dictionaries were created. The keys of the dictionaries are the serial numbers of the disks. I don’t really like the solution in the form of a pack of dictionaries, but I haven’t yet come up with a better one.


This is what the main window of the program looks like.

Each disk in the program has a mode in which it is located. The default idle mode is idle. When you run a test, this mode is changed to the name of the test being performed. The test process regularly checks the compliance of the mode with its name and, if it does not, interrupts the test. Thus, the main process can interrupt the test by changing the disk mode to idle. The program can run embedded SMART tests on disks (Short and Extended), check disks by sequential reading and writing. In this case, the recording test is made cyclical, prescribing the disk again and again, noting how many cycles were done. Continuous loop recording allows you to “finish off” discs that have a “spill” surface, but which have not yet scored the necessary number of errors to return to the supplier. In a few days in this mode, they usually reach the SMART status bad state, which is the reason for the replacement. On the screen, the test shows the speed of the test (where possible), the number of disk errors and the number of "slow" sectors. The time after which the sector is considered “slow” is given by a constant in the program. The program can also show basic information on the disk, SMART and the logs of SMART tests.



A write test can prescribe a disk with both zero values ​​and a unique pattern by which it can be determined that the disk has already been tested by this program. The write method is also switched by a constant. Since the program was designed to load the test environment over the network, it has the ability to disable the exit from the program menu.

Here such a utility turned out, maybe someone will come in handy. The utility code and the library on which it is built is available on github.