I'd like to try running a firmware updater for a USB hard drive enclosure.
Supposedly TRIM can be enabled via the updater, but it requires Windows 7.
The host is an 8GB Pi4 running 32bit RaspiOS. The updater is at
It isn't entirely clear the updater is needed, but running it seems prudent.
I've tried WINE, but it reports BAD FORMAT, I gather the result of the
updater being written for i386 architechture.
Is there any other way to proceed? I don't own any modern i386 hardware,
nor a Win7 license and don't realy want to buy either. I do have an old
Xeon box, but it probably doesn't have enough RAM to install Windows 7.
The WINE version installed using apt reports
wine-4.0 (Raspbian 4.0-2)
Might a later version of WINE help, if it can be found and made to run on
Thanks for reading!
If the drive is USB I'd be looking at Qemu's USB passthrough at a minimum: I
doubt WINE would support such access. However, given the risk of bricking
the drive if the firmware upgrade goes wrong, I would much prefer to do this
on a real Windows box. Much less chance of something breaking halfway
Yes, the drive is USB. I agree completely that using a native Windows box is
best, but I don't have one.
Apt search reports a bunch of qemu-related packages, one of which is called
qemu-system-arm/stable 1:3.1+dfsg-8+deb10u8 armhf
QEMU full system emulation binaries (arm)
Would that be the package to try? It's unclear to me if -arm refers to
the host architecture or the emulated architechture....
Thanks for posting!
If you do mind the risk of bricking the drive, please buy, beg or
borrow a genuine Windows 7 box for the upgrade.
These hardware guys' Windows programs are particularly fussy
about really running on Windows (and the version suggested).
Unless you've put other architectures in your /etc/apt/sources.list
(or associated files), then you should only be seeing packages for
ARM host architecture. That one presumably applies to running ARM
emulation on ARM, "armhf" at the end indicates that it's an ARM
But I'd agree with others here that the odds of this all working are
very much against you. WINE and QEMU are both extra layers that have
pretty dodgy support for what you're doing. WINE's hardware USB
support isn't clearly documented, but might be mainly geared at
things like game controllers which are HID devices. HIDs work more
simply than other USB devices like your HDD.
If you set up a real Windows installation in QEMU, that gives you
a bit more likelihood of success, but I still wouldn't bet on it.
it is the emulated architecture
you would need the -x86 package on the rpi. Consider that then you have to
install windows7 in the qemu. I have no idea how good it is supported. But
if the drive is so important, given the risk that you can brick it and the
time and work you will invest, wouldn't be it better to buy a used laptop
with windows7 on it?
In the past when WINE hasn't worked but I really needed to run
Windows software on a current Windows release (the Australian
government's tax return submission software - thankfully now
implemented as a website), I used an "internet computer" at the
local library. Since moving, I found that the local community centre
offers a similar local service, though I haven't had to try that yet.
It seems more cost-effective to keep searching for a USB-SATA enclosure or
adapter that correctly supports the Pi4's implementation of UASP. Even a
rather expensive adapter will be cheaper than a second-hand laptop if a
candidate can be identified.
It's a bit surprising that nobody has collected a list of suitable adapters.
Perhaps one is out there, but I've not found it in considerable looking.
Then again, it may all be a wild goose chase. The drive and adapter I'm
using now, a Sabrent EC-UASP, works in a subjectively acceptable way. The
sticking points are a report that the firmware upgrade is needed to support
TRIM and a poor performance report from the Pi's SD card speed test utility:
Raspberry Pi Diagnostics - version 0.5
Sun Dec 13 07:48:49 2020
Test : SD Card Speed Test
Sequential write speed 100979 KB/sec (target 10000) - PASS
Random write speed 300 IOPS (target 500) - FAIL
Random read speed 63 IOPS (target 1500) - FAIL
Sequential write speed 83912 KB/sec (target 10000) - PASS
Random write speed 318 IOPS (target 500) - FAIL
Random read speed 67 IOPS (target 1500) - FAIL
Sequential write speed 58671 KB/sec (target 10000) - PASS
Random write speed 169 IOPS (target 500) - FAIL
Random read speed 91 IOPS (target 1500) - FAIL
This is with a 5400 RPM mechanical hard disk, so rotational latency
precludes excellent random performance. Still, the subjective "feel"
of the machine is reasonably good; it's fast enough to use as a
chromium browser workstation.
It's unclear if the adapter supports trim as-is. One report on Amazon's
review pages says the update is required. An examination of the system
per the instructions at
suggests the adapter and hard drive both support TRIM:
Maximum unmap LBA count: 65535
Maximum unmap block descriptor count: 8
Unmap command supported (LBPU): 1
In addition, the disk reports:
Data Set Management TRIM supported (limit 8 blocks)
suggesting it's an SMR drive.
I attribute the acceptable performance to the drive being new,
with 1 TB capacity. Once it starts re-writing old sectors it'll
likely slow much more.
Thanks for reading this far!
AFAIK trim isn't supposed to do anything useful to a hard drive
regardless of speed or capacity, but I know nothing about SMR, except
that an article I just read says its really only suitable for large scale
data storage with minimal updating, i.e. not something I'd use for the
(main? only?) storage volume for a Linux or Windows system and definitely
not for a journalled fling system.
Practically, SMR is not readily avoidable. It's denser and therefore cheaper
than conventional perpendicular recording and has found its way, unbidden, to
a wide range of sizes, speeds and brands. The drawback is that, like flash,
data is written in relatively large blocks. Writes to an entirely unused
block proceed without a delay. Changes to an already-written block require
it be copied, edited and re-written in much the same fashion as flash, absent
the write fatigue problems of flash. Trim functions on an SMR drive much as
it does on a flash device, preemptively preparing new, empty blocks for prompt
use by consolidating partly-used blocks accumulated during earlier writes.
When something triggers a long period of sustained writes, like reconstructing
a raid array, this overwhelms the preparatory consolidation and slows writes
to a crawl. It's not that it doesn't work, rather that it works badly.
I should emphasize that this summary is my own interpretation of a random
selection of Internet research, and is therefore entirely suspect......
Thanks for reading,
I've drawn the same conclusions as you, from what I've read. With one
small exception: I believe that, if you dig deeply enough into the
manufacturer's specification, you can see whether a particular drive
uses SMR, and therefore avoid it if you so wish.
Apparently that is a comparatively recent development. There were complaints
that SMR was deployed without warning. In the case of my drive, specs at
the drive is advertised as PMR but also supports TRIM. AFAIK there's little point
in having both. There is also no spec for write speed, only read. The combination
is at least a little suspicious.
Exactly what's going on is unclear. Certainly, it pays to check first.
Thanks for writing!
Useful to know.
Next question: how to find out whether a WD hard drive is plain old disk
I bought a pair of 1GB WD Elements at the beginning of 2019 for use as
weekly backups that are kept offline when not actually doing a backup.
I'm using rsync to back up 4 computers (3 running 64 bit Fedora, the
fourth is an early 512MB Rpi B) so all other things being equal, I'd
expect to see backup activity to be pretty consistent for each machine,
which is what I'm seeing: in no case have I seen the sort of slowdown
which is apparently noticeable with SMR disks.
So, my guess is that these are not SMR, but who knows: I haven't found
any indication of drive technology in the so-called data sheet for for
these drives on the WD website - just a not that WD feel free to mix and
match drive type between production batches.
Is there any other site that would know/admit what type of drive is in
these WD Elements sealed units?
Martin | martin at
Gregorie | gregorie dot org