a) which USB-to-SATA bridge is used (any user that currently has a PiDrive attached to a host might be able to post the output of ‘lsusb’)
b) is the USB-to-SATA bridge SAT/S.M.A.R.T. capable so that self tests can be triggered and S.M.A.R.T. parameters can be read out?
c) how does the drive’s firmware handle the LCC (load cycle count) problem when I store my rootfs on the HDD (heads parked after 8 seconds and shortly after unparked)?
d) is it possible to adjust drive spin-down (when idle) through ‘hdparm -S’?
e) what about performance when used on a SBC without limited USB support? Eg. an ODROID-C1/C1+ or when using USB3.0? Anyone?
EDIT: OK, I found that WD uses a custom product ID (idVendor=1058, idProduct=07ba which is currently not supported by smartmontools) and that performance is as horrible as to be expected on any RPi with its only one USB2.0 connection: ~10MB/s according to this poster.
Ok, not that many responses so far
In the meantime I recompiled the kernel for my RPi to be able to use UASP and tested with iozone.
pi@raspberrypi:~ $ zgrep USB_UAS /proc/config.gz
Unfortunately that doesn’t help, RPi can not benefit from UAS:
[ 8.118269] usb-storage 1-1.2:1.0: USB Mass Storage device detected
Here are the iozone results – settings as described here: http://linux-sunxi.org/USB/UAS
KB reclen write rewrite read reread
4096000 4 34561 34116 36825 36425
4096000 1024 34754 34179 37322 37283
In other words: I get 34.5/37 MB/s with a JSM567 USB-to-SATA bridge using btrfs (choosing any other filesystem or disabling btrfs compression for USB disks attached to Raspberry Pis is just insane )
Ok, no need to think about the PiDrive any longer. If the performance is really just ~10MB/s as reported by others and if it’s impossible to query S.M.A.R.T. values and given the long history of WD drives dying way too fast due to the LCC problem when used with Linux using the PiDrive seems to be the worst possible way to access an external HDD.
WD Smartware 1.6x used with Windows PCs has the ability to alter parameters on WD external drives.
Thus LCC can be modified to correctly work as rootfs.
Regarding performance, ~10MB/s is rather low. I would expect better. Since the USB2 on the Raspberry Pi is shared through a USB hub on board, are there other USB peripherals active sharing this bandwidth?
Another note on performance
Raspberry Pi USB2 is a single lane bi-directional simplex bus (D+/D-), while USB3 has separate Tx / Rx lanes for full duplex operation. USB3 can take advantage of UAS full duplex operation with data transfers in both directions simultaneously. But ultimately the USB to SATA bridge reverts to SATA which is command/response with data traffic one direction at a time.
In other words UAS will not result in a performance gain on a USB2 bus.
Nice to hear but of course completely useless here: We’re not talking about Windows but Linux. If I’m not able to use hdparm/smartctl to set parameters and query this important parameter then I would not use such a drive.
Also: What about disk sleep (spindown/spinup). No one here knows or even cares. Simply the wrong place to ask (and better to avoid this drive)
I thought that also but half a year ago I had to learn that’s not true. UAS is more efficient than BOT. On SoCs where UAS is supported we’re able to reach 40 MB/s: http://forum.armbian.com/index.php/topic/504-quick-review-of-orange-pi-pc/?p=3244
And it should help also with random I/O a lot.
Use Smartware (yes in Windows) to set the spin down times, I think they should be persistent across power cycles, then move the drive to Linux and you should be good.
Yes UAS gives you command queuing which makes things more efficient and result in better performance.
Maybe this is a misunderstanding. I speak both about HDD spin-down and the LCC problem (parking the heads after 8 seconds of inactivity just to unramp them a few seconds later and parking/unparking the drive to death).
Spinning a disk down after n minutes of inactivity is also an important feature since why should a disk waste energy and rotate the platters when it’s not needed? I want both to be able to send a drive to standby/sleeping state and being able to prevent the head parking/unramping.
But since I’m not able to monitor the drive using S.M.A.R.T. (and maybe hdparm also doesn’t work so I can not controll sleep/standby state) and it’s said to be slow as hell I refrain from thinking any longer equipping a few ODROID-C1+ with it.
The PiDrive’s cable solution is smart but since the drive’s capabilities are that limited it’s a no-go.