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 https://www.sabrent.com/download/ec-uasp-update/
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 --version
wine-4.0 (Raspbian 4.0-2)
Might a later version of WINE help, if it can be found and made to run on
the Pi4?
No because WINE isn't a CPU emulator - it's a compatibility layer
that translates Windows API calls. If your program is compiled for
x86, you'll need something that can execute x86 instructions.
https://wiki.winehq.org/ARM
QEMU has some support for passing physical USB devices over to
software running in emulation: https://qemu.readthedocs.io/en/latest/system/usb.html
Links for setting up x86 WINE on a Pi using QEMU are aplenty: https://wiki.winehq.org/Emulation (see bottom for what you presumably
had in mind originally) https://sourceforge.net/projects/pi-qemu-wine/ https://www.novaspirit.com/2019/04/15/run-x86-arm/
No because WINE isn't a CPU emulator - it's a compatibility layer
that translates Windows API calls. If your program is compiled for
x86, you'll need something that can execute x86 instructions.
https://wiki.winehq.org/ARM
QEMU has some support for passing physical USB devices over to
software running in emulation: https://qemu.readthedocs.io/en/latest/system/usb.html
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 through.
Theo <theom+news@chiark.greenend.org.uk> wrote:
If the drive is USB I'd be looking at Qemu's USB passthrough at a minimum: >> 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
through.
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!
bob prohaska
Theo <theom+news@chiark.greenend.org.uk> wrote:
If the drive is USB I'd be looking at Qemu's USB passthrough at a minimum: >> 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
through.
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....
Would that be the package to try? It's unclear to me if -arm refers to
the host architecture or the emulated architechture....
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.
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.
bob prohaska wrote:
Would that be the package to try? It's unclear to me if -arm refers to
the host architecture or the emulated architechture....
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?
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.
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.
On Sun, 13 Dec 2020 16:38:29 +0000, bob prohaska wrote:
I attribute the acceptable performance to the drive being new,AFAIK trim isn't supposed to do anything useful to a hard drive
with 1 TB capacity. Once it starts re-writing old sectors it'll likely
slow much more.
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.
Martin Gregorie <martin@mydomain.invalid> wrote:
On Sun, 13 Dec 2020 16:38:29 +0000, bob prohaska wrote:
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.
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......
In message <rr5vtr$21r$1@dont-email.me>
bob prohaska <bp@www.zefox.net> wrote:
Martin Gregorie <martin@mydomain.invalid> wrote:
On Sun, 13 Dec 2020 16:38:29 +0000, bob prohaska wrote:Practically, SMR is not readily avoidable. It's denser and therefore
I attribute the acceptable performance to the drive being new, with 1AFAIK trim isn't supposed to do anything useful to a hard drive
TB capacity. Once it starts re-writing old sectors it'll likely slow
much more.
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.
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......
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.
AFAIK trim isn't supposed to do anything useful to a hard driveWD SMR drives support TRIM.
regardless of speed or capacity,
On 13/12/2020 19:13, Martin Gregorie wrote:
AFAIK trim isn't supposed to do anything useful to a hard driveWD SMR drives support TRIM.
regardless of speed or capacity,
On Mon, 14 Dec 2020 09:15:10 +0000, druck wrote:
On 13/12/2020 19:13, Martin Gregorie wrote:Useful to know.
AFAIK trim isn't supposed to do anything useful to a hard driveWD SMR drives support TRIM.
regardless of speed or capacity,
Next question: how to find out whether a WD hard drive is plain old disk
SMR.
Is there any other site that would know/admit what type of drive is in
these WD Elements sealed units?
But, for my Seagate, I found two sources, both from Seagate, that seem
to disagree. The first: https://www.seagate.com/internal-hard-drives/cmr-smr-list/
implies all 2.5" Barracuda drives use SMR
The second
reports "perpendicular magnetic recording", which implies not SMR.
I don't know which to believe.
I think Seagate are specifically referring to drives currently on themarket,
not past models. It's also not unusual for manufacturers not to disclose about USB drives, only SATA drives. Previously SMR was only on very large drives (8+GB) but recently it's started creeping into smaller drives (to
save costs, not that drive prices have come down much).
It might help to check these: https://www.truenas.com/community/resources/list-of-known-smr-drives.141/
https://itigic.com/smr-hard-drive-this-is-the-list-of-models/ https://nascompares.com/2020/04/16/your-wd-red-nas-hard-drives-might-be-using-smr-what-you-need-to-know/
I don't know which to believe.
Its interesting that the WD blurb on Elements portable USB drives
basically says "the drive type inside is whatever we had in the stock bin when we did the production run", so either I got lucky, since mine seem
to give fairly consistent backup times, or the current production policy
was introduced after I got mine in early 2019.
not past models. It's also not unusual for manufacturers not to disclose about USB drives, only SATA drives. Previously SMR was only on very large drives (8+GB) but recently it's started creeping into smaller drives (to
save costs, not that drive prices have come down much).
I don't know which to believe.
If you have the drive plugged in, run:
smartctl -a /dev/sdX
(may have to install smartmontools package)
That should tell you the model number of the drive mechanism inside the USB enclosure. Then Google for that.
Martin Gregorie <martin@mydomain.invalid> wrote:
On Sun, 13 Dec 2020 16:38:29 +0000, bob prohaska wrote: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.
I attribute the acceptable performance to the drive being new,AFAIK trim isn't supposed to do anything useful to a hard drive
with 1 TB capacity. Once it starts re-writing old sectors it'll likely
slow much more.
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.
AFAIK, SMR doesn't hurt performance until the drive starts re-writing previously-used sectors, rather like flash. If your drives haven't
reached that point, they'll function roughly like CMR (also called PMR) devices. Given the capacity of SMR drives, it might make sense to just
use them as approximately write-once devices.
It shouldn't be in drives intended for NAS usage. The 8-TB Toshiba N300s I bought a couple months ago don't do SMR, and it looks like they offer capacities up to at least 14 TB. Look for "CMR" as the antonym of SMR.and
Looking at Toshiba's other drives, it appears the only ones that use SMR are their 2.5" drives. Seagate only uses it in 2.5" drives and their Barracuda and Archive drive families. Western Digital uses it in at least some 2.5" drives and some Blue and Red drives (what's troubling is that the Red drives are supposedly for NAS use, though all Red Pro drives and Red drives 8 TB
larger are CMR).
It would seem that avoiding SMR isn't as difficult as it may have first appeared, though you are going to pay a bit more for drives that don't use it.
It remains fairly difficult if I want a 2.5" drive rather than 3.5".l200/
Is there some special trick for finding them? By pure luck I found
this:
https://www.toshiba-storage.com/products/toshiba-internal-hard-drives-
which reports that these drives use CMR:
HDWJ110UZSVA,
HDWK105UZSVA,
HDWJ105UZSVA
On Tue, 15 Dec 2020 23:51:30 +0000, bob prohaska wrote:
It remains fairly difficult if I want a 2.5" drive rather than 3.5".l200/
Is there some special trick for finding them? By pure luck I found
this:
https://www.toshiba-storage.com/products/toshiba-internal-hard-drives-
From the stuff you posted it appears that all WD 2.5" 500GB Blue and
which reports that these drives use CMR:
HDWJ110UZSVA,
HDWK105UZSVA,
HDWJ105UZSVA
Black drives and 1GB Red drives are CMR.
Similarly all WD 3.5" drives of 1TB or smaller are CMR and so are larger
Red Pro, Black and Purple.
That is for drives made in the first part of 2020 - after that its
anybody's guess
That doesn't help much. The drive model is ST1000LM048-2E7172
The two Seagate documents still disagree. It's possible TRIM
support was added pre-emptively, since firmware is free once
written.
Its somewhat unclear to me what exactly TRIM is meant to improve when
used on an SMR drive: I can see that it would be a big help if it could defragment files etc, but surely that can't be done at the drive level
since it implies some knowledge of the filing system's logical structure?
bob prohaska <bp@www.zefox.net> wrote:
That doesn't help much. The drive model is ST1000LM048-2E7172
The two Seagate documents still disagree. It's possible TRIM
support was added pre-emptively, since firmware is free once
written.
Googling indicates it's SMR: https://www.truenas.com/community/resources/list-of-known-smr-drives.141/
The gist is that published specs aren't necessarily a reliable guide. Eventually it'll likely get clarified, but for now, in the 2.5" 1 TB
class of drives, SMR is difficult to reliably avoid.
On Wed, 16 Dec 2020 15:31:44 -0000 (UTC)
bob prohaska <bp@www.zefox.net> wrote:
The gist is that published specs aren't necessarily a reliable guide.
Eventually it'll likely get clarified, but for now, in the 2.5" 1 TB
class of drives, SMR is difficult to reliably avoid.
At that size either you use an SSD (NVMe for preference) or you're penny pinching.
On Wed, 16 Dec 2020 15:31:44 -0000 (UTC)
bob prohaska <bp@www.zefox.net> wrote:
The gist is that published specs aren't necessarily a reliable guide.
Eventually it'll likely get clarified, but for now, in the 2.5" 1 TB
class of drives, SMR is difficult to reliably avoid.
At that size either you use an SSD (NVMe for preference) or you're penny pinching.
On Wed, 16 Dec 2020 21:33:07 +0000, Ahem A Rivet's Shot wrote:
On Wed, 16 Dec 2020 15:31:44 -0000 (UTC)
bob prohaska <bp@www.zefox.net> wrote:
The gist is that published specs aren't necessarily a reliable guide.
Eventually it'll likely get clarified, but for now, in the 2.5" 1 TB
class of drives, SMR is difficult to reliably avoid.
At that size either you use an SSD (NVMe for preference) or you're
penny pinching.
Price difference between HDD and SSD are fairly close. eBuyer is flogging:
- 2.5" WD Blue 500GB SATA for £37 (probably CMR)
- Samsung 500GB SATA drives for £63.00
or a PNY [never heard of em] 480GB SATA drive for £40.
On Wed, 16 Dec 2020 21:33:07 +0000, Ahem A Rivet's Shot wrote:
On Wed, 16 Dec 2020 15:31:44 -0000 (UTC)
bob prohaska <bp@www.zefox.net> wrote:
The gist is that published specs aren't necessarily a reliable guide.
Eventually it'll likely get clarified, but for now, in the 2.5" 1 TB
class of drives, SMR is difficult to reliably avoid.
At that size either you use an SSD (NVMe for preference) or you're
penny pinching.
Price difference between HDD and SSD are fairly close. eBuyer is flogging:
- 2.5" WD Blue 500GB SATA for ?37 (probably CMR)
- Samsung 500GB SATA drives for ?63.00
or a PNY [never heard of em] 480GB SATA drive for ?40.
Last I checked SSDs were a little worse for power consumption, but
that was months ago and I don't know where the trend is going.
Yes. I've run this desktop now on SSD for as long as a spinning rust
disk used to run and its SMART errors are well in hand.
Unless you want super high capacities, I see no point in spinning rust
at all. I've 6GB of rust in my server, yes, but I would be happy to
replace it with SSD when it starts to fail, if the price were similar.
That struck me as odd, so I googled.
The balance of opinion is exactly the reverse. SSD uses up to 5 times
*less* power?
This spec
gives operational power on a SSD of ~3-4 watts and idle power 56mw. In
most applications due to the high read and write speed the operational
times will be very short.
shows far higher figures for read write and idle...
On 17/12/2020 01:47, bob prohaska wrote:
Last I checked SSDs were a little worse for power consumption, but
that was months ago and I don't know where the trend is going.
This spec
ssd-2879-800092.pdf?_ga=2.57708201.28239759.1543588356-1527752628.1543588356
gives operational power on a SSD of ~3-4 watts and idle power 56mw. In
most applications due to the high read and write speed the operational
times will be very short.
shows far higher figures for read write and idle...
As evolution plays out it may well favor SSD.
For now HDDs seem to
be developing the same handicaps as SSDs. I think HDDs still win
on write cycles and power consumption. Not sure how they compare for practical life span. Life span is a function of overprovisioning for
SSD, if SSD costs keep dropping they might win on both counts.
Last I checked SSDs were a little worse for power consumption, but
that was months ago and I don't know where the trend is going.
On 17/12/2020 01:47, bob prohaska wrote:
As evolution plays out it may well favor SSD.
That's done and dusted,
For now HDDs seem to
be developing the same handicaps as SSDs. I think HDDs still win
on write cycles and power consumption. Not sure how they compare for
practical life span. Life span is a function of overprovisioning for
SSD, if SSD costs keep dropping they might win on both counts.
Last I checked SSDs were a little worse for power consumption, but
that was months ago and I don't know where the trend is going.
The problem I see ahead for SSDs is the move to QLC (4 bits per cell),
at the cheaper end, which has an order of magnitude less life than TLC
(3 bits per cell).
Although this was said for the move from SLC (1 bit per cell) and MLC (2
bits per cell) to TLC, but that has provided pretty rock solid over the
last 6 or 7 years, with the use of advanced controllers, wear levelling
an over provisioning.
It might be useful to re-frame the issue in terms of failure mode. If a machine fails gracefully, how long it's going to last becomes much less worrisome. If a storage device gives warning that it's running out of
write capacity I might not be afraid of QLC vs lower-density options.
If it just goes all bricklike, with no warning at all, it's a lot less attractive. Just the ability to test how much over-provisioning remains available would be a big help. SMART keeps some track of deterioration
in mechanical drives, does it exist for SSDs?
SMART keeps some track of deterioration
in mechanical drives, does it exist for SSDs?
I have had a mix of drives on many Ubuntu Linux desktops and Raspberry
Pi over the last 15 to 20 years.
In all that time I think I have had two disk drives (both spinning
ones) fail.
Disk drives are *amazingly* robust and reliable. For example my first serious backup NAS was a WD 'my book' with two 1Tb drives, this ran continuously as my backup system with daily backups sent to it for six
or seven years. I only retired it because the disks filled up. I
recently booted it to try and find some old files of my daughter's, it
booted fine (and I found the files, more than ten years old).
I have a Lenovo laptop which is SSD based and I've steadily migrated
my desktop system to being SSD based. They're all carefully backed up
so if the SSDs die I'll be OK but so far I've not had any SSDs fail,
some must be quite a few years old now.
The current backup system is a Pi with an external, spinning, 8Tb
drive. This isn't very old yet so I've no data.
In my limited experience SSDS are ALREADY more long-lived than disks and
more reliable. Even under fairly heavy usage. They are just expensive.....
On 17/12/2020 20:32, bob prohaska wrote:Intel X25-E SSDs 32GB:
SMART keeps some track of deterioration
in mechanical drives, does it exist for SSDs?
Absolutely. It's mandatory more or less. It gives you error rates on all
the things you need to worry about. This drive has been going a shade
over 5 years of actual 'on' time as my linux desk top boot drive: data
is held on a server so it doesn't get much action. But logs are written
to this. So it has in fact more writes than reads! (9780 GB versus 5255GB)
It still reports 95% of its useful life left.
============================================
I've just tested my first SSD, which is still in use. An 11 year old
On 18/12/2020 00:45, The Natural Philosopher wrote:
On 17/12/2020 20:32, bob prohaska wrote:Intel X25-E SSDs 32GB:
SMART keeps some track of deterioration
in mechanical drives, does it exist for SSDs?
Absolutely. It's mandatory more or less. It gives you error rates on
all the things you need to worry about. This drive has been going a
shade over 5 years of actual 'on' time as my linux desk top boot
drive: data is held on a server so it doesn't get much action. But
logs are written to this. So it has in fact more writes than reads!
(9780 GB versus 5255GB)
It still reports 95% of its useful life left.
============================================
I've just tested my first SSD, which is still in use. An 11 year old
Power_On_Hours 54141
Media_Wearout_Indicator 98.
Although to be fair I'm not sure all SSDs are as reliable. I did buy a
number of OCZ SSDs (about 4), all of which failed catastrophically, I'm
not sure what the wearout indicator was on them.
On 18/12/2020 10:57, Pancho wrote:
On 18/12/2020 00:45, The Natural Philosopher wrote:
On 17/12/2020 20:32, bob prohaska wrote:Intel X25-E SSDs 32GB:
SMART keeps some track of deterioration
in mechanical drives, does it exist for SSDs?
Absolutely. It's mandatory more or less. It gives you error rates on
all the things you need to worry about. This drive has been going a
shade over 5 years of actual 'on' time as my linux desk top boot
drive: data is held on a server so it doesn't get much action. But
logs are written to this. So it has in fact more writes than reads!
(9780 GB versus 5255GB)
It still reports 95% of its useful life left.
============================================
I've just tested my first SSD, which is still in use. An 11 year old
Power_On_Hours 54141
Media_Wearout_Indicator 98.
Although to be fair I'm not sure all SSDs are as reliable. I did buy a
number of OCZ SSDs (about 4), all of which failed catastrophically,
I'm not sure what the wearout indicator was on them.
I think the consensus seems to be that a reliable brand will these days outlast spinning rust, and given that unless you have a CPU/DRAM
failure, that happens is blocks go bad and are mapped out which is a
very graceful failure mode.
So provided you check with SMART once a year you should not have *catastrophic* failure. My failure was pretty hard and happened in less than a year.
The current backup system is a Pi with an external, spinning, 8Tb
drive. This isn't very old yet so I've no data.
On 2020-12-17, Chris Green <cl@isbd.net> wrote:
The current backup system is a Pi with an external, spinning, 8Tb
drive. This isn't very old yet so I've no data.
Is this a 2.5in or a 3.5in? If 3.5in what USB adapter do you use?
cheers
Jim
On 2020-12-17, Chris Green <cl@isbd.net> wrote:
The current backup system is a Pi with an external, spinning, 8Tb
drive. This isn't very old yet so I've no data.
Is this a 2.5in or a 3.5in? If 3.5in what USB adapter do you use?
On 18/12/2020 12:20, The Natural Philosopher wrote:
On 18/12/2020 10:57, Pancho wrote:You are describing a graceful/designed failure mode. As I remember it,
On 18/12/2020 00:45, The Natural Philosopher wrote:
On 17/12/2020 20:32, bob prohaska wrote:Intel X25-E SSDs 32GB:
SMART keeps some track of deterioration
in mechanical drives, does it exist for SSDs?
Absolutely. It's mandatory more or less. It gives you error rates on
all the things you need to worry about. This drive has been going a
shade over 5 years of actual 'on' time as my linux desk top boot
drive: data is held on a server so it doesn't get much action. But
logs are written to this. So it has in fact more writes than reads!
(9780 GB versus 5255GB)
It still reports 95% of its useful life left.
============================================
I've just tested my first SSD, which is still in use. An 11 year old
Power_On_Hours 54141
Media_Wearout_Indicator 98.
Although to be fair I'm not sure all SSDs are as reliable. I did buy
a number of OCZ SSDs (about 4), all of which failed catastrophically,
I'm not sure what the wearout indicator was on them.
I think the consensus seems to be that a reliable brand will these
days outlast spinning rust, and given that unless you have a CPU/DRAM
failure, that happens is blocks go bad and are mapped out which is a
very graceful failure mode.
So provided you check with SMART once a year you should not have
*catastrophic* failure. My failure was pretty hard and happened in
less than a year.
my OCZ failure mode was that the device just failed to be recognised by
BIOS, i.e. not blocks wearing out gracefully. I don't think anything
showed up on SMART. By the time these disks failed they had been
relegated to bin-able laptop boot drives, no important data, so I didn't investigate. My assumption is that a component in the controller board failed. But the effect was a sudden total loss of all data on the disk.
These OCZ drives were bought circa 2013. I've not had problems with any
of my other SSDs Intel, Crucial, Kingston, Samsung.
However, I think it is one of those questions were the diagnosis is irrelevant, we all know the correct treatment: good short term backups.
I've using rsnapshot recently, which I have found great, simple enough
for an incompetent like myself.
I've using rsnapshot recently, which I have found great, simple enough
for an incompetent like myself.
All my irreplaceable data is rsynced overnight. Handy when I
accidentally delete something - last night's backup is still there.
All my irreplaceable data is rsynced overnight. Handy when I
accidentally delete something - last night's backup is still there.
On Sat, 19 Dec 2020 04:47:46 +0000, The Natural Philosopher wrote:
All my irreplaceable data is rsynced overnight. Handy when I
accidentally delete something - last night's backup is still there.
Try rsnapshot: its fast (uses rsync to make backups) and lets you have
more than just the last backup version available.
daily and keep 4 weekly backups, which means it keeps 7 daily backups, combining the dailys every week to make a new backup, which is kept for a month. as each 'backup' is simply a list of pointers to timestamped file copies, the rsnapshot backup set seems to be about twice the size of a
single rsync backup and making the weekly snapshot takes twice as long to make as the daily one, i.e. 8 minutes compared with 4 minutes for the
daily run and the complete set is 183GB.
For comparison, when I previously used compressed gzip daily backups,
these took 3.5 hours and I could only fit 4 daily backups on a 320 GB
disk.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 80:57:41 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,309 |
| Posted today: | 1 |