USB3 Seagate External 5TB Drive Painfully Slow

  • I'm out of SATA ports and bays on my OMV box so I decided until I had more time to relocate files and replace with larger drives, I would just attach a Seagate USB3 external drive. Was able to both initialize the drive as ext4 and mount it no problem.


    It's plugged into a USB3 port on my tower.


    Here's the issue - Performance is just terrible when copying files to or from the device. Gets as fast as 4 MB/s and then stalls all the way down to 200 KB/s before gradually getting up to 4 MB again, then droping back down, etc. Most of the time it's around 500 KB/s.


    So slow that it seems to bog down the entire system as far as response time, not just the drives involved in the copy. I've tried it both over SMB as well as NFS and directly over SSH. It just seems that the speeds writing to this 5TB USB Seagate external are EXTREMELY slow.


    I seem to recall having a similar issue prior to this when attempting to attach an external drive and then just gutting the case and putting the drive on SATA. Am I doing something wrong or is there anything I can try? Is there a way to determine if the ports I am connecting to on the case are truly USB3 and not just USB2 (and would USB2 explain the slowness)? They are labeled as 3.0 ports but perhaps the case was assembled wrong and they're connecting over to USB2 busses on the mobo?


    Any thoughts most appreciated.

    • Offizieller Beitrag

    Do you have the backports 3.16 kernel installed? There is a button to install it in omv-extras.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • @ryecoaaron make a 3.16 kernel more usb3 performance?

    omv 6.x | 64 bit | omvextrasorg 6.x |
    used plugins: omv-extras | portainer | rsnapshot | antivirus
    used container: portainer/portainer | nextcloud/all-in-one | linuxserver/swag | paperless-ngx | jellyfin/jellyfin | lmscommunity/logitechmediaserver | adguard/adguardhome |

    • Offizieller Beitrag

    I wasn't even sure if the 3.2 kernel fully supported usb3. Install it and try it. if it doesn't work, the 3.2 kernel isn't uninstalled and you can pick the kernel that boots in omv-extras.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Hi guys,


    Not sure why I am not seeing replies, I must be going nuts. Thanks. Anyway...I have the drive connected to a USB3.0 port on the tower and am sure 3.0 ports are all set to active.


    I am using the 3.16 kernel right now.


    It seems that OMV is able to boot and see the drive, but doing things like attempting to do a large file copy (I cp'ed some stuff from one volume to the external via the shell overnight, woke up to the deadlock again). It seems to do OK when it's the only thing happening on the system, but as soon as a second proceess happens (in this case, it was a sabnzbd download unopacking), everything sort of breaks down.


    When I try to access the volume this morning via ssh or visually in Windows, it freezes and doesn't report back.


    From the log:


    Jun 26 09:08:22 WallMedia kernel: [34238.381250] sd 6:0:0:0: [sdg] Command timed out
    Jun 26 09:08:22 WallMedia kernel: [34238.381259] sd 6:0:0:0: [sdg]
    Jun 26 09:08:22 WallMedia kernel: [34238.381263] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    Jun 26 09:08:22 WallMedia kernel: [34238.381267] sd 6:0:0:0: [sdg]
    Jun 26 09:08:22 WallMedia kernel: [34238.381269] Sense Key : Not Ready [current]
    Jun 26 09:08:22 WallMedia kernel: [34238.381275] sd 6:0:0:0: [sdg]
    Jun 26 09:08:22 WallMedia kernel: [34238.381278] Add. Sense: Logical unit is in process of becoming ready
    Jun 26 09:08:22 WallMedia kernel: [34238.381282] sd 6:0:0:0: [sdg] CDB:
    Jun 26 09:08:22 WallMedia kernel: [34238.381284] Read(10): 28 00 3f 48 01 41 00 00 09 00
    Jun 26 09:08:22 WallMedia kernel: [34238.381297] end_request: I/O error, dev sdg, sector 8493468168

    • Offizieller Beitrag

    Looks like the drive is starting to fail. Does it have issues when using it under Windows?

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Works great under windows. It's a seagate external drive 5tb brand new out of the shrink wrap.


    I had a similar problem with another usb external drive I tried to use with OMV so I yanked it out of the case and put it into a 2 bay esata enclosure which worked better.


    Any suggestions on getting a usb external drive to play better? This is the second one that's acted the same way for me.

  • I've unmounted the drive for now and am running some fsck commands on it. OMV really hates it when I have this drive up though and I constantly get "communication error" thrown by the GUI as soon as I attempt to copy any files to it. Even with it unmounted, the whole system seems really unhappy when I connect a USB drive and try and copy files over to it.


    This is more than likely some weird configuration thing that I am doing wrong. Is there an easy way I can just grab some log items for anything related to this drive, sdg, and post here to see if you see anything funny? There an easy way to do that? Not sure where to start and copy/pasting from the log in the GUI doesn't seem possible.

  • Started a almost similar thread ... this seems to be a relevant problem. Is no one else making backups on usb3. I on the trail to shop a used esata case to test that issue on another hardware, that desperate I am ... I'm complaining, backup must be a central issue, or ma I wrong?


    Micha

    ____________________
    Grüße aus Berlin


    Q29000-ITX
    omv 4.1.8.2 | 64 bit | backport kernel | omvextras

  • My problem may be a little different though -- It just has to do with general read/write performance of the system overall when sending data to/from an externally connected USB drive.


    I wonder if taking a look at the logs (a certain section) might help. Just in the interest of helping the developers. This may also be something that is just a natural side effect of the way things work. I notice a significant spike in CPU usage while the copies are running and the USB drive is seeing heavy use. If I then try and access the drive otherwise (steam a file from it, get a directory listing, etc) -- Forget it. The entire system spikes to 100% CPU usage and craps out.


    I checked my BIOS to make sure that I'm not overworking it or something and everything certainly seems on the level to me. But there must be something I am doing here that is causing OMV to not like passing data via the USB channel (perhaps it's the combination of drives in the system that is causing the bottleneck, since all the file moves taking place are internal).


    I'll try and post more detail if I can, I realize these are not easy problems to solve, but I'd sure love to be able to use this external USB drive without troubles since I am fresh out of SATA ports inside this machine.

  • See anything weird? This all from syslog:


    Jun 27 10:27:23 WallMedia kernel: [83638.888807] EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl
    ....snip...
    Jun 27 11:06:47 WallMedia kernel: [ 2.721394] sd 6:0:0:0: [sdg] 625142448 512-byte logical blocks: (320 GB/298 GiB)
    Jun 27 11:06:47 WallMedia kernel: [ 2.721646] sd 6:0:0:0: [sdg] Write Protect is off
    Jun 27 11:06:47 WallMedia kernel: [ 2.721650] sd 6:0:0:0: [sdg] Mode Sense: 23 00 00 00
    Jun 27 11:06:47 WallMedia kernel: [ 2.721909] sd 6:0:0:0: [sdg] No Caching mode page found
    Jun 27 11:06:47 WallMedia kernel: [ 2.721947] sd 6:0:0:0: [sdg] Assuming drive cache: write through
    Jun 27 11:06:47 WallMedia kernel: [ 2.723959] sdg: sdg1 sdg2 < sdg5 >
    Jun 27 11:06:47 WallMedia kernel: [ 2.725306] sd 6:0:0:0: [sdg] Attached SCSI disk
    ....snip.....
    Jun 27 11:06:47 WallMedia kernel: [ 3.148591] EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: (null)
    Jun 27 11:06:47 WallMedia kernel: [ 3.313434] usb 6-5: string descriptor 0 read error: -22
    Jun 27 11:06:47 WallMedia kernel: [ 3.313475] usb 6-5: New USB device found, idVendor=13d3, idProduct=3393
    Jun 27 11:06:47 WallMedia kernel: [ 3.313477] usb 6-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    ...snip...
    Jun 27 11:06:47 WallMedia kernel: [ 9.354911] sd 6:0:0:0: [sdg] Unhandled sense code
    Jun 27 11:06:47 WallMedia kernel: [ 9.354915] sd 6:0:0:0: [sdg]
    Jun 27 11:06:47 WallMedia kernel: [ 9.354917] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    Jun 27 11:06:47 WallMedia kernel: [ 9.354918] sd 6:0:0:0: [sdg]
    Jun 27 11:06:47 WallMedia kernel: [ 9.354919] Sense Key : Medium Error [current]
    Jun 27 11:06:47 WallMedia kernel: [ 9.354921] Info fld=0x0
    Jun 27 11:06:47 WallMedia kernel: [ 9.354923] sd 6:0:0:0: [sdg]
    Jun 27 11:06:47 WallMedia kernel: [ 9.354924] Add. Sense: Unrecovered read error
    Jun 27 11:06:47 WallMedia kernel: [ 9.354926] sd 6:0:0:0: [sdg] CDB:
    Jun 27 11:06:47 WallMedia kernel: [ 9.354926] Read(10): 28 00 00 00 03 30 00 00 08 00
    Jun 27 11:06:47 WallMedia kernel: [ 9.354931] end_request: critical medium error, dev sdg, sector 816
    Jun 27 11:06:47 WallMedia kernel: [ 9.354969] Buffer I/O error on device sdg, logical block 102
    ...snip...
    Jun 27 11:06:47 WallMedia kernel: [ 14.712365] Adding 7179260k swap on /dev/sdg5. Priority:-1 extents:1 across:7179260k FS
    Jun 27 11:06:47 WallMedia kernel: [ 14.722056] EXT4-fs (sdg1): re-mounted. Opts: (null)
    Jun 27 11:06:47 WallMedia kernel: [ 15.330584] EXT4-fs (sdg1): re-mounted. Opts: errors=remount-ro


    File system seems to keep unmounting and remounting as read-only, etc.


    I realize on paper this looks like a bad external drive, however this is the 3rd USB drive I have tried to use on OMV on this system as a device connected via USB, and everyone one gets read/write errors and has this symptom, every time I have tried. I have to think it's a software or hardware issue here, or the way the drive is being accessed by OMV.


    I can confirm CPU usage at idle is around 7%, and as soon as I try any operations to the connected USB drive, CPU spikes to 80% - 100% usage during the entire copy operation until the drive spins down. Something's not right.

  • ryecoaaron,


    Let me apologize -- I was mistaken on the quality of this drive. I found a driver to read the drive in ext4 format under Windows, and it's DEFINITELY messed up. The drive worked well as an NTFS drive for Windows for some time, however, OMV seemed to eat this thing for breakfast somehow.


    I was reading some posts around the web about some external drives not being suitable to work with Linux/Debian and as a result that the drive basically was having its hardware corrupted by the system? Is it possible that the way I have this thing configured in OMV or set it up is causing it to quickly deteriorate?


    Thankfully, Seagate has a warranty on this and I'm going to swap it out once I get as much data off it as I can (it was just a video backup drive, nothing that cant be replaced).


    If I hook up the new one and the same thing happens to the new drive, can I assume OMV or Debian is eating this drive alive? Hopefully you have some ideas of what I can check/try when I configure the replacement drive to make sure I'm not setting something up wrong.

    • Offizieller Beitrag

    OMV/Debian/Linux didn't kill the drive. A lot of USB externals get really hot and fail quicker than most.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Thanks for sticking with me. So it's reasonable to assume that within 2 weeks a new out of the box external USB drive could be killed by the system? If that's the case, seems to be a good reason for no one to ever want to connect an external USB to OMV.


    Are there any settings/configurations I can make to a physical disk in the settings when I add it to have OMV go easier on the device? I don't need the thing to be lightning fast, reliability is the key here. It's just storing or streaming video.

  • Can I ask you one more question too, since you have been so kind.


    If my CPU usage is at 0%, and when I initiate any operation to an externally connected USB drive to copy files (to/from) and CPU usage is spiking up to 80-90% while that operation is taking place, is it safe to assume that I have something wrong that is happening either with my configuration or with my hardware? Or is that a normal thing to see during a large file copy operation, for 80-90% of CPU to be used?


    I am running with 4GB of RAM in an AMD A6-5400 CPU box headless, onboard graphis, all sound disabled (trying to soak out as many resources as I can).


    I will note I have 6 drives connected internally as well as an external eSATA enclosure with 2 more drives in it. Not sure if that eats up overhead but I do idle at 0%.


    I can do some rsyncs using the internal SATA drives if you would like a benchmark. I imagine the CPU usage during an RSNYC from sata drive to sata drive is a lot less than when doing an rsync involving the external USB drive for some reason (though I can't say why?)

  • More detail here (and maybe I should start a new thread).


    CPU usage is spiking from 0-4% into the 80-90% during ANY file copy/rsync operation between internal drives. USB external drive does not seem to be the factor at all here. Any file move/copy operation seems extremely taxing on the OMV system.


    I have my drives set up as AHCI in the bios. Anything else I could be missing here. I may have been looking at the wrong place all along. External USB just may be more susceptible to data corruption due to the way it's connected or something.


    My guess is that CPU usage should not be spiking like this during an internal file copy operation?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!