jbartlett

I wasn’t aware that a Diagnostics report would help with Plugins. Here you go. nas-diagnostics-20180412-1021.zip

Following the steps in this linked post to partition & format a NVMe drive allowed UD to be able to mount the NVMe drives. Formatting via UD wouldn't allow the NVMe drive to mount via UD.

That's something the scans from the HDDB will show. I've received a feature request to include the scans from the HDDB to compare with a drive benchmark which will show if someone's drive is outside of the norm. http://strangejourney.net/hddb.cfm?View=models&Vendor=Seagate&Model=ST8000AS0002

I've got two of those drives. My benchmarks show similar lines.

That should be fixed in the next beta. Potential for a race condition.

Share a picture. If the hump is at the start, some Seagate drives are like this where the first 25GB-50GB is much slower. Keep an eye on the drive and see if the graph changes over time.

Thanks for continuing to test it guys. I've got over 80 drives in my "Not found" folder which is helping to fine tune vendor & model detection. So far, 138 unique drives has had information uploaded and 66 models have benchmark data.

Well, if ya got a spare one of those too... haha I almost went with a system close to that before going to the Ryzen 1950X.

Well, if you happen to have a spare controller laying around that's the same that won't detect, I'm willing to pay for shipping here & back. But baring that, I'll be adding additional diagnostics for reporting in the next beta that'll help me figure out the controllers.

I answered one of them on the 2nd post on this page (page 3) which may help you get past the spindown issue. Spin up all your drives and set the checkbox to disable SpeedGap testing. I haven't added unraid's spin-up method, it's on my to-do list.

If unraid can see it, then it's simply a matter of understanding how the drives are laid out in the OS under /sys/devices. SATA, SAS, and NVMe drives are all represented differently. The best way to do it is to have such a controller but I've already made too many expenditures to pick up a card to add support right now. If you're willing to help me find the information to add support (will be a bit of back-n-forth), send me a PM. I'll also add support for a "Unidentified Controller" to stick any orphan drives under.

Frontier in my area. Finally came back up after 14 hours and looks like it may be sticking around. I don't think their tech support is allowed to say what's causing the outage even if they know. Personally, I think the number of cat pics in the Seattle area hit a critical threshold.

Speed gaps are where the minimum & maximum speeds during the test had a sizeable gap which may indicate drive activity. You can disable that on the test selection screen.

Submitting drive info & benchmarking won't work currently, there's an Fios outage in my area for over 6 hours now. Been meaning to work on better catching network errors like that, now's my chance! (trying to jinx the issue to be fixed)

Interesting theory. Most of his drives are doing that.

Dude. What you've been getting shouldn't be possible. SSD's should always be a nice smooth line. In fact, earlier today I took the graphs off the HDDB and replaced it with an average read speed over the entire drive because graphs are practically useless for SSD's.

Beta 3a posted Single thread the process which analyzes & cleans up the benchmarks to prevent against a race condition where two threads try to process it at the same time Reworked how NVMe drives are detected Scan all PCI root ports for controllers Modified IOMMU detection If you had missing drives or couldn't get past the scanning hardware screen, please update and try again. If you can't get past the Scanning Hardware screen, change the URL from http://[ip]:[port]/ScanControllers.cfm to http://[ip]:[port]/isolated/CreateDebugInfo.cfm and hit enter.

I agree! haha

Needed to purge all the uploaded benchmarks due to how the last 100% scan spot was given. When the benchmarking process reads the spot just prior to 100%, it sees how much data was read and then moves back from the end of the drive that amount plus a couple extra blocks. It was marking the start of the last block as the scan position instead of as the total capacity of the drive itself. On the HDDB, this resulted in scans from multiple people having different end points based on the negotiation between the drive & OS for the optimal block size and the graphs would have a flat line at the right end. In a previous beta, I fixed that so the last spot at 100% is recorded as happening at the end of the drive instead of the offset but there was no way I could easily identify sets of data in the table since there was no field grouping sets together. Now there is. Benchmarks will continue to float in over time to rebuild the HSDB and I'll be able to manually fix any benchmarks where the last spot which doesn't match the drive capacity. The drive information in the HSDB wasn't touched.

That looks like an issue with one of the docker hub mirrors. If you try again after after a short bit, it may work. But there's nothing I can really do to fix it that I can think of other than making another push.

Can you run this URL? Plug in the IP with your unRAID IP address or just copy & paste everything after the port http://[ip]:18888/isolated/CreateDebugInfo.cfm

Got it, thanks! Working on adding code to let me switch between debug files and load the exec results instead of actually executing the command.

Beta 2d uploaded Add Scroll to Top button Save the last benchmark spot as the capacity of the drive instead of the computed offset where it reads from to reach the end of the drive