Attaching USB grinds My Cloud to a halt

Just purchased my My Cloud… in the process of setting this up.

I have noticed that when my USB3 drive is attached everything grinds to a halt, the WebUI, mac app, all become completely unresponsive and give me network ‘timeout’ messages if I try and refresh the page. Soon as I remove the USB drive everything returns to normal speed.

The USB drive is a WD Passport with 3 partitions, 2 HFS and one NTFS.

I am on the latest firmware.

Any ideas?

Even after removing the USB drive ‘top’ command in SSH shows a really high IO wait

%Cpu(s): 0.9 us, 2.9 sy, 0.0 ni, 0.0 id, 95.5 wa, 0.0 hi, 0.7 si, 0.0 st

Same here.  I purchased a WDMyCloud 3T a few days ago and have the latest firmware (v03.01.04-139) installed.

Within a few minutes of connecting my Seagate FreeAgent 1T USB drive, the WDMyCloud  becomes completely unresponsive.   Running ‘top’ in an ssh shell (before it slows downs) shows the output of top getting slower and slower.  It eventually gets to a point where it takes over a minute just for one line of the top output to be printed.  The usage reported by top at that point is:

top - 23:55:26 up 37 min, 1 user, load average: 26.45, 26.57, 21.95
Tasks: 88 total, 3 running, 84 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0.1 us, 71.8 sy, 0.0 ni, 0.0 id, 22.7 wa, 0.0 hi, 5.4 si, 0.0 st
KiB Mem: 230560 total, 162212 used, 68348 free, 756 buffers
KiB Swap: 500732 total, 48920 used, 451812 free, 108 cached

It looks like kernel processing is very high, and still plenty of free memory available.  The wdmcserver process is using the most CPU at the time.  However, given that it is taking multiple minutes to output one snapshot of top, the process-specific output may not be accurate.

I’ve had the USB drive for more than a year, and is approx 70% full of existing backups.

I tried inserting a 4G USB stick (also mostly full), but didn’t see the problem.

I’ve resorted to backing-up the WDMyCloud by connecting the USB drive to my Windows 7 computer.  However, that solution has not been without headaches.  The Safepoint failed at less than 1% complete for a 95G backup.   Multiple attempts to retry failed.  I finally just tried running rsync directly in an ssh shell.  It too failed at some point.  Looking at the logs on the Windows 7 computer hosting the USB drive showed the error mentioned in this link:

Applying the fix appears to deal with the Windows problem that caused the shared drive to become unavailable and result in rsync failing.  I’ll try again to use the Safepoint feature of the WebUI some time since that’s part of why I went with a solution such as this instead of building up a linux box for this purpose.