jbartlett

I just discovered the reason behind DiskSpeed's controller benchmark low scores. The dd command progress MB/sec speed indicator is an overall average, not the speed over the last second as I had assumed. dd includes the spinup delay in it's speed average calculations. The following command against my Parity drive spun up shows top speed right away but much slower speeds that slowly climb if the drive was spun down. Take note if you use dd to test your workaround. dd if=/dev/sdh of=/dev/null bs=1310720 skip=0 iflag=direct status=progress conv=noerror

This is likely two different issues that present in the same way. I spun down my drives connected to the MB controller and performed a DiskSpeed controller benchmark and was able to duplicate.

Your USB device is annoying. 😁 I added an existence check for that variable and looked for other potential misses and repushed version 2.9.3

This issue isn't due to UNRAID OS. For anyone getting this issue, spin up your drives first before running a controller benchmark. The cause is that my spin-up logic isn't working. The first second of the 15 seconds if data read is discarded to account for any drive head relocation but the spin up times is causing at least one second of 0 MB/sec read which is hurting the average. This issue isn't evident on the individual drive benchmarks because it performs seek & latency tests first so the drive is spun up before it gets to the benchmark.

Good news: It's not your system! I spun down my drives and ran a controller benchmark and I got the same results. The drive benchmark performs a couple seek tests & a latency test on the drive prior to benchmarking so it's pretty much assured to have the drives spun up when it actually starts reading the drive via the dd command. The controller benchmark doesn't do those tests prior. I need to revisit the spin-up logic.

All would be telling. Notably if the drives on one controller is higher than drives on another. In theory, they should all be roughly the same. If it looks like they are, just a number. It should be given in milliseconds or 1000=1 second. The dd command outputs a status every second so if it takes longer than I accounted for, I may need to increase the number of seconds to drop from the start.

Can you provide that information?

The average speed logic discards the first read which includes any potential spinup / drive head placement. It might not be dropping enough in your case. Does your SMART data include spin up time?

Clicking on the "Benchmark Drives" button on the home page (click on the "DiskSpeed" header) allows you to benchmark all controllers at the same time with controller testing each drive attached to it in sequence.

The error in the USB Bus tree stopped the rest of the page from displaying which prevented you from seeing the Benchmark All button. I pushed version 2.9.3 which checks for the existence of the idProduct variable and sets it if not created by the USB device.

My DiskSpeed app uses the dd utility to read the drive for 15 seconds for each drive on the controller in succession, then the same command against each drive all at once. To get slower speeds during single-drive reads vs multiple drive concurrent reads is weird. I'd have to say that it's not my app but my app is showing the issue at hand.

Deployed version 2.9.2 which will ignore virtual USB hubs

Can you show me how you have the USBIP module vhci_hcd set up so I can duplicate the issue as you have it configured?

Are the most recent tests reflecting a line near the bottom of the graph? If so, then yes, I'd say it's likely a failed drive. Interesting enough, the SMART report doesn't show any bad sectors - which is pretty much the reason I created this app. If the more recent drives show the reads near the top of the graph but with a dip in the middle, I'd be interested in taking this drive off your hands to use for testing version 3 of the app. If it's all flat towards the bottom, I've already have a drive doing that.

I'd run an extended offline smart test on the drive, then check the smart report. If that doesn't show anything, perform a parity check which will read the entire drive, then check the smart report again. Or first swap out the drive, rebuild the replacement, and then check out what's up with the drive. I have a test drive that is flatlining on the benchmark and the smart report is all over the place with errors, even more so after I did a full read of the drive.

My backplane matches that one. I've been searching to see if the SAS drive can provide any extra information on the file system but so far I haven't found anything. If you could, could you create a full debug file with controller information and email it to me at [email protected]? The full debug file includes a copy of the sys bus tree with every small read only file included and it'll let me dig into it to see if having a physical SAS drive will be helpful.

What kind of connection do they have? My dev server has a backplane that has SATA & SAS connectors but they're both in the SATA form.

Glad you updated before I went out and bought a cheap SAS drive. 😁 I added the WD6001FFWX model but if you have others that show up without an image, you can view the drive and edit it to add one. You can also do this if you prefer alternate or rebranded images 'cause WD seems to come out with new ones every year.

It should like them but some code intended for version 3.0 got accidentally included and it fetches information on the drive partitions and it looks like the "parted" command isn't liking your drive. Can you visit this URL (replace the IP for your unRAID server) and create a debug file with controller info? http://192.168.1.7:18888/isolated/CreateDebugInfo.cfm The file will be large so please don't attach it here. Please email it to [email protected]

FYI - if you have an issue with your drive images defaulting, update the docker app and it'll be restored.

Can you visit this URL (replace the IP for your unRAID server) and create a debug file with controller info? http://192.168.1.7:18888/isolated/CreateDebugInfo.cfm The file will be large so please don't attach it here. Please email it to [email protected]

Okay guys, can you update the Docker and try again? I re-wrote the image fetch logic again to use a different method of referencing the drives. It's hard for me to duplicate some of these conditions because I don't have the drives in question. If you get an error, please reference the error in your reply but you don't need to include the long stack trace. It doesn't provide any value. I added a feature where if it couldn't find the drive by Vendor / Model (such as an invalid vendor where some SSD's return "ATA"), it'll search all the vendors to try to find a match on the model ID and sets the vendor to a match.

I think I see what's going on here. The app creates a reference by Vendor & Model so that multiple drives of the same kind can be quickly cross referenced. SSD's are notorious for not listing a Vendor or listing the incorrect vendor. If you could, please attach or email me at [email protected] the file storageref.json located in appdata/DiskSpeed/Instances/local ? I want to see how the drives are being referenced on your setup.

Pushed version 2.9.1. Some stuff for version 3.0 got pushed into 2.9.1 as a result of the above issue. Added the rest of the support for optimizing the drive images after downloading to ensure the CSS for centering any text overlays is correct. Drive Edit: Fixed the Z index which prevented click-n-dragging the slider for horizontal placement of the text if the text layer was rotated. This image optimization may change how your thumbnails look. If it does, then the CSS behind it wasn't properly set up which this corrected. If you make any changes to a drive image, be sure to submit your changes and your particular edits will be restored in the event a full scan is done (such as deleting the DiskSpeed appdata directory). Note that the edits are system specific, if you have more than one UNRAID server, you'll need to make the same changes to each & submit.