I am extremely disappointed with WD. I emailed tech support and was provided with a variety of solutions that did not apply to my situation. They have concluded that my drive is defective and have issued a RMA. I am returning it for repair/exchange. I personally feel that there is no problem with the hardware.
I take issue with the earlier statement that you get what you pay for and that this is an entry level unit.
The unit was not free, nor does it perform as advertised. This is ridiculous and borders on fraud. If the unit can’t meet the specs and WD can’t correct it than we should be able to return the unit for full credit. The vendor I purchased it from has declined to take it back.
I hope I am totally wrong and when I get the new unit it will be wonderful. I will be glad to post that. I must give WD some credit for hosting this board and allowing all the negative press.
This is truly harassing my work. I am an editor and bought this unit to safely store my footage. And we are not getting the right answers. I just don’t know how to retrieve all my data to transfer it to another NAS unit. This is so disappointing. WD really cheated on us by doing wrong advertising. We could sue them if we find the right lawyer! all problems could be solved if they would not ignore us, move their asses and find a solution for their customers. But obviously they give a sh… . this is not nice!
Bill, I mean, think about this: I am waiting now for 5 hrs to get some video files transferred from my mac to the NAS. And the funniest thing is, on the Copy window is permanently written “About 5 seconds”. I am an editor and I paid over 1,000$ for this WD ShareSpace which was falsely promoted as 1gig fast storage. THAT was the reason why I bought it and put so much data already on it. Under wrong believe this unit was sold to me and this situation is harassing my work.
Therefore: don’t you see yourself able to find a solution for this bottleneck problem?
Unfortunately applying the patch didn’t help so much. Without the patch we had transfer rate both to and from the WD Sharespace ~10 Mbytes/s. (It’s a new device we bought just a few weeks ago. It was configured as RAID 5 by the manufacturer and the only thing we did was updating the firmware. However before the update the speed was not significantly greater). After applying the proposed patch upload speed increased to 14 Mbytes/s, and download speed increased to 20 Mbytes/s. (We measured the rates by transferring large gigabyte file to and from the device via the SMB and FTP protocols. Ethernet cables and the switch we used were ok – we tested them, they fully complied with gigabit ethernet).
Assuming the slow rate was caused by RAID 5 reduncy we tried to configure the storage both as RAID 0 and SPAN. Unfortunately it didn’t help.
For our application we need the upload speed to be at least 50 Mbytes/sec. Could you please tell if this problem will be solved within a few weeks? If not we will have no other choice but to return the device to the seller, because we have deadlines approaching.
I may have a solution for some users. I have the latest firmware release as well as the patch from the posting above.
Despite those patches, I was still experiencing very poor upload performance (2Mbp/s!) to the WD server from my Vista-based PC ( note - and this is important - it has no Vista service packs installed ) .I fired up an SSH connection to the WD Sharespace and ran the linux top command and did a large Windows file copy to the server. smdb on the WD Sharespace ran at 99.9% cpu and was continuously increasing its memory usage - after it reached 53 MB Ram (about 40% of the WD’s total RAM) I terminated the copy. There’s obviously a coding problem and a memory leak in smbd. I tested an ftp connection to the server and it ran at pretty good speed with no problems, so that exonerated all other components (network, disk, cpu etc).
Clearly there is an smdb problem. I then tried another Vista PC of mine which has Vista SP1 installed and there were no memory or cpu problems with smdb on the WD ShareSpace, and upload performance was much better (continuous 90Mbp/s). Apart from the service pack, both Vista machines have the same configuration, both have the same network MTU’s and both connect to the same switch.
So - a potential solution for users with Vista is to ensure at least SP1 is installed. If that fails or you don’t have Vista, try using ftp or any of the other protocols that the WD ShareSpace supports and avoid the Windows CIFS service on the WD ShareSpace.
The best solution would be for WD to find a better release of smbd.
Update on my note about Vista SP1 above - after a few more hours of copying, my Vista SP1 also caused a problem with smbd - but the characteristics are a little different - the smdb cpu is running at around 60% which is ok, but smdb is now starting to uncontrollably consume memory - it’s now at 58MB and climbing.
WD needs to supply a newer smdb release - the release currently on the SS (3.0.34) has several security and bug updates that ought to be installed (3.0.35 → 3.0.37). The 3.0 series is no longer supported by Samba - the last release for it was over a year ago - and thus any important security or bug fixes are not going to be developed. The currently release of Samba is 3.5.6 - for Samba’s release history see http://www.samba.org/samba/history/
To get round the problem with samba, I’m exploring rsync and would like to know if anyone has successfully implemented windows to SS copying via rsync.
Take it off the gig switch and put in on a 10/100 switch. You may get a scale factor of 10 improvement in performance. I was lucky to get 600K on my gig switch (pretty frustrated - you bet!). I moved it over to my 10/100 network and it’s moving qucker. still WAY TOO slow for the cost.
With the 1gig switch I found the MTU setting was critical. When the MTU was set at around 9,000 bytes, the max speed was 2Mb/s, but setting the MTU to around 4,000 bytes, the speed is up to around 80Mb/s.
I’ve got rsync going very nicely now, directly from my Windows Vista machine to the WD ShareSpace - the free Windows GUI rsync tool that I’m using even includes scheduling of backups. Rsync (which is actually part of the WD ShareSpace linux distribution ) runs on both boxes and checks the contents of the files, and only transfers updated files, and only the sections within a file that have changed - so backup efficiency is very good. Rsync doesn’t have the bugs exhibited by smbd - it’s been running for about 12 hours continuously now with no memory leaks and CPU is about 70%.
For baseline backup, I’m getting about 8M Bytes / sec transfer speed (around 70Mbits/sec over the LAN) - I’ll experiment with a 100/10 switch instead of the 1G and see if I can improve it.
This rsync combo could be packaged as an easy to use and efficient backup tool for the WD SS.
My rsync backups continue to operate continously with few problems. The current backup of about 1.5TB of files has caused some memory growth in the rsync daemon on the WD SS - 29MB RAM so far, but it’s nowhere near as bad as the smbd daemon, and tranfer speed is still ok. The nice thing about rsync is I can stop and restart it anytime and it doesn’t re-copy everything that’s already been copied.
I tried the 100/10 MB switch, but it made no difference - there was a slight degradation in performance. I think the real issue is the size of the MTU’s. With a 100/10MB switch the WD SS automatically disables Jumbo frames, thus removing any problems a 9,000 byte MTU could have caused. This means that rather than using a slower switch, simply ensure your Jumbo frames are around 4000 bytes.
One setting I did spot on the WD SS that is cause for concern was the ‘nice’ setting of -20 !!! for the smbd daemon in the init.d script. That’s the highest priority setting in a Linux box and processes really shouldn’t be set that high - they can drain performance from related services which can slow down the overall performance.
It’s fun being able to tinker with the WD SS and I’m grateful WD opened it up - I just hope they supply a better distribution of the O/S and Samba.
