search

mbuesch / disktest

Hard Disk (HDD), Solid State Disk (SSD), USB Stick, SD-Card tester
https://bues.ch/h/disktest
Apache License 2.0
34 stars 5 forks source link

Feature enhancement possibly ? #2

Closed simonmcnair closed 7 months ago

simonmcnair commented 7 months ago

This looks interesting, https://github.com/bingmann/disk-filltest?tab=readme-ov-file.
I has an -U mode which may be an idea to incorporate in to your app (https://panthema.net/2013/disk-filltest/) which "The only option requiring more explanation is -U. In this mode, the tool will create the files random-######## as usual, but will immediately unlink() them from the file system (the directory stays empty). On Linux this is possible, because the tool can keep the file descriptors open and perform the usual write/read/verify sequence. The mode is very useful for batch checking, because the system will automatically free the used disk space when the program finishes, whether successfully or with an error!"

I prefer your app as it's rust. Just an idea. I would also apprecaite any pro's and con's of each app as they both seem to do a very similar job.

mbuesch commented 7 months ago

Hi. Thanks for your suggestion.

I don't understand what is the benefit of unlinking the file after opening the file descriptor. Could you please explain when this would help? What is "batch checking"? Thanks.

simonmcnair commented 7 months ago

I was under the impression that after you have written and tested a segment you can delete it. thus you do not need to fill the disk, and you could, in theory, run it while using the system ? in my case, I am checking a hba, so I am more interested in reading and writing, rather than the disk itself. I am running debian linux and writing to a file rather than an entire disk.

I guess arguably if you want to test the whole disk then the entire thing needs to be blank as advised in the readme information.

mbuesch commented 7 months ago

I would strongly suggest to not do any fill test on a disk that is in active use. No matter what tool is used. The reason being that there will always be the point in time where the disk is 100% filled and writes from other applications will fail. Even if this moment is only very brief.

However, I think the unlink-after-open approach is flawed for another reason and this makes it impossible to implement this in disktest: disktest ensures that the operating system caches are flushed after finishing the write. Otherwise, the read-verify could (partially) be served from the OS cache. Which would completely void its whole point of testing the disk itself. But doing this requires closing the file descriptor and re-opening it after flushing. At which point the file would be deleted by the OS, if it was unlinked before.

But there is another feature in disk-filltest that could potentially be useful, though: Split the test file into multiple files. This could be useful on limited or old filesystems like FAT that can't have huge files.

simonmcnair commented 7 months ago

I'm sure you're correct. I just thought I'd raise your awareness of the project so that if there were any enhancements that were of use, or conceptual improvements it could be considered. Cheers

mbuesch commented 7 months ago

Thanks for your help. I will track the split-file approach in #3.