jbartlett

When ever I tried to schedule one to kick off daily in 15 minutes, it's only ever kicked off the check for Drive 3. It finished and nothing else started. *shrug*

A workaround is to export the drive and then check the export on that drive.

The "Show Problems" link doesn't show the problems. Clicking the link opens a popup dialog with no contents. The file /var/tmp/disk1.tmp.end does exist.

It'll report something like "1 mismatch (updated)" or "1 corruptions"

Feature request: Export by share so hashes from different machines can be compared against each other without manipulating the export files. For example, comparing files between a primary server and a backup server with different drive layouts.

I've gotten it to run under a different unix OS (I forget which) but the main thing you need to ensure is Privileged=true. This is also the main reason why DiskSpeed doesn't work in Windows because it doesn't support that flag. From there, it's just experimentation.

Search your syslog file for "recovery thread". It'll list block numbers that failed. Issue is you really don't know which drive the fail came from. I recently run into this issue with one of my drives and currently adding support to the version 3.0 of DiskSpeed to search your drives to find what files occupy that spot on all of the drives for further checking. If you have 3+ errors (I had 100+), look for a pattern such as 1,4,8,12 where it skips 3 or some number each time - that's a sign that one side of a platter is failing. It could be on your data drives, it could be on your parity drive. I'd also recommend getting the "Dynamix File Integrity" plugin.

The only way I can see how to invoke a scan of a drive is to go to the app's settings and change the cron job and drive settings to kick off the validate process in the next available time slot.

Amazon isn't doing any counterfeiting. Someone sold fake stuff to Amazon and Amazon didn't catch it. For their part, Amazon evidently doesn't keep the same (apparent) stock from different sources separate.

I've been working on adding support for benchmarking SSD's and wanted to post my method for others to weigh in on. The method I came up with allows DiskSpeed to come up with the following metrics using a Western Digital Black NVMe 250GB, model WDS256G1X0C: Read Speed: 427 MB/s Write Burst Speed: 202 MB/s (ends after 7.52GB) Write Sustained Speed: 118 MB/s - 149 MB/s There needs to be at least one partition mounted with at least 15GB of free space available. In this example, I will use "/mnt/cache". SSD's in a RAID or drive pool will not be tested as it is not possible to test just one drive in the series. The commands given below are formatted for repeating on your personal setups. For best results, shut down any VM's or active Dockers residing on the cache drive. 1. Sync drive sync "/mnt/cache" 2. Trim drive fstrim -v "/mnt/cache" 3. Create 10GB file with random data dd if=/dev/random of="/mnt/cache/DiskSpeed_fq9.junk" bs=1MB count=10000 conv=noerror status=progress 2> /boot/cache_write.txt 4. Sync drive sync "/mnt/cache" 5. Read the file dd if="/mnt/cache/DiskSpeed_fq9.junk" of=/dev/null iflag=direct status=progress 2> /boot/cache_read.txt 6. Delete the file & trim the drive again The line delimiter used for cache_read.txt & cache_write.txt is just a carriage return so you will need to use a program that can understand that such as Notepad++ or it will all appear on one line. The last line in cache_read.txt is used for the read speed. 10000000000 bytes (10 GB, 9.3 GiB) copied, 23.4231 s, 427 MB/s The cache_write.txt file is read line by line looking at the number of bytes read, the current duration, and speed. 203000000 bytes (203 MB, 194 MiB) copied, 1.00453 s, 202 MB/s When the number of seconds from the last line compared to the current line is more than 2 seconds, then the drive's buffer was filled and there is a pause while the drive flushed some of buffer to make room. The highest value taken up to this point is considered the Write Burst Speed as it utilizes the drive cache memory. The number of bytes at the current line (gap in the seconds) is Write Burst End value. From that point on, the Min-Max speeds are computed for the write sustained speed range.

I'd recommend updating your shares to exclude the drive in question until you get the new one in.

Check your SMART values. Swap out the drive and let the parity rebuild it. If you're curious, run an extended SMART test after you move the files off and see if your SMART values have changed when it's complete. Alternately, run a single-cycle/pass preclear (read/write once) on the drive which should flush out any pending bad sectors.

RAID drives aren't currently supported but will be in version 3.0 though it still shouldn't hang like that. I'll take a look.

I'm pretty sure it works but I'll look into it. And you're right about the checkbox. I'll build a patch soon. I don't actually make use of the library but I know the whole thing with "Some tool you may use might use it". What antivirus/malware do you have? It looks like the input/output butter is getting messed with. I know I've recently run into issues with Acronis's protection in that it intercepts the whole buffer and won't release it until it's closed. Fucks with programs that stream HTML intermediately such as updating scanning progress. Haven't heard of IOzone. I'm using dd to read from the drive from a given location for a given duration with the bitbucket as an output.

It's supposed to preserve whatever image you put but I was able to duplicate your issue. After applying your image, you should now see a "Submit Drive" button - click on it and then click on it again to confirm. This should also allow the image to restore after a rescan.

A second text layer - should be somewhat simple to implement. I'll add it to the 3.0 To Do list. (The 2.9 line is bug fixes only now.)

Sorry for the delay in responding, just haven't had much time for hobby programming of late. I dug through the file you sent and the related hardware and so far I got nothing. I might be able to decern more using a full debug file but .... <shrug> Hard to tell unless I have the PCIe card & drive too. It might be driver related in unraid/qemu (edit: Docker) in that it doesn't have one that supports this combo while the Windows VM does.

Can you create a regular debug file and email it to me? Link and info is on the bottom of the DiskSpeed app screen. This way I can look at what the system is reporting for the drive.

It's odd that the drive reported different speeds. The Samsung PM1733 has a max read speed of 6,400 MB/s based on this spec video but your speeds are much slower for the SSD. Only recommendation I have is to verify that you have it connected to a PCIe Gen 4 interface. It kinda looks like a gen 3 speed.

Apologies, I misread your question and my brain flipped the numbers. If you don't mind, let's try two tests against the drive. The first test duplicates how DiskSpeed performs a benchmark at the start. In these examples, I'm testing against /dev/sdd - change the drive reference to reflect your PM1733. This first test you will need to break out to stop. Test 1: dd if=/dev/sdd of=/dev/null bs=1310720 skip=0 iflag=direct conv=noerror status=progress Now let's do the same but against a file. Locate a large file and change the if= reference to point to it. Test 2: dd if=/mnt/disks/SSD_327E/Cam1/OS.qcow2 of=/dev/null bs=1310720 skip=0 iflag=direct conv=noerror status=progress Test 2 is how I plan to have version 3 of DiskSpeed to perform a benchmark. What are the transfer speeds?

NVME & SSD drives only provide normal benchmarks with the current DiskSpeed version if the drive has been written entirely (such as a single preclear write pass) or filled up. If a benchmark is read on a brand new SSD, it'll report reads off the chart because the drive knows if that spot has ever been written to previously and if not, returns null's without accessing the memory. The next version will have a new method of testing the read/write speeds of solid state mediums by either finding and reading a large file or writing & reading back a large file. When the next version will be released is anyone's guess. I'm a married man now, my development time is thus nipped.

Can you share the error screen? From the list of actions being taken to the error message - no need to include the long java stack, just the error message and where it occurred.

Interesting. You might be right. I'll be keeping an eye on it and will monitor the syslog.

Just had something odd happen. I needed to look up the <progress> HTML tag for another project and I ran my DiskSpeed app and hit a benchmark on a random drive and did an inspect on the HTML of the progress tag to get it. I could have just googled it but ah, I digress. I noticed that the speed was flat lined at 141MB/sec. I let it finish and it started to go down towards the very end but was flat up until that point. I ran subsequent tests and they all showed the same thing - a max bandwidth of 141MB/sec while all other drives on the same controller (motherboard) behaved normal. I did a power off reboot and now everything is back to normal. I didn't think to save off the syslog so no checking that. Anyone else have had this happen to them?

Wondering what you mean by "feel slow". But those are good speeds. Try running a controller benchmark to see if a controller isn't able to handle all the drives active at the same time. I'll get a read speed from each drive one after the other and again all at the same time and compare the two. From what I see, you're using an onboard controller with three drives out of a possible six. It looks like it should be able to handle it fine. You can also try running a disk benchmark at with a 1% interval scan (101 scan points vs the default 11) which might help locate questionable areas. The next major release of DiskSpeed will add support for full surface level testing but I don't have a timeline for that release. I'm currently slammed at my job and I haven't had much time of late for hobby programming.