jbartlett

Community Developer
  • Content Count

    1677
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by jbartlett

  1. 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.
  2. I think I follow what you're saying. The parity rebuild should function the same as forcing a write on each sector and then verifying that write - but you'll be at a greater risk of a party rebuild failing since all sectors must report OK.
  3. I did that with mine. But in your case, I'd copy (not move) files onto it and then do a binary/crc compare on the files to ensure they're identical. Beyond Compare by Scooter Software can help with this. Then once a match is verified, remove the source.
  4. 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
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. 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.
  12. 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.
  13. If the file names are unique, creating a copy of the files in a single directory for both versions and then using Beyond Compare to compare the directory, missing files will be easy to spot.
  14. 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.
  15. Deployed version 2.9.2 which will ignore virtual USB hubs
  16. 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?
  17. 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.
  18. 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.
  19. 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 harddrivedb@gmail.com? 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.
  20. 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.
  21. 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.
  22. 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 harddrivedb@gmail.com
  23. FYI - if you have an issue with your drive images defaulting, update the docker app and it'll be restored.