Products > Computers

let's face it: usb-sticks are not reliable

(1/12) > >>

DiTBho:
Back to 2011, I bought a couple of usb-sticks from Amazon, TDK and Sandisk brand new sticks, supposed to be "decent quality" for a kind of backup kind of backup you carefully store inside a locker and don't touch for years.

Yesterday night I mounted those usb-sticks in my Linux box to read some old files and ...

--- Code: ---sd 7:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 7:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current]
sd 7:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
sd 7:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 1c 42 1e 00 00 f0 00
blk_update_request: critical medium error, dev sdc, sector 1851934
sd 7:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 7:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current]
sd 7:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
sd 7:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 1c 42 a8 00 00 02 00
blk_update_request: critical medium error, dev sdc, sector 1852072
Buffer I/O error on dev sdc1, logical block 926005, async page read
 sdc: sdc1 sdc2 sdc3
sd 7:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 7:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current]
sd 7:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
sd 7:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 7a e0 60 00 00 f0 00
blk_update_request: critical medium error, dev sdc, sector 8052832
sd 7:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 7:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current]
sd 7:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
sd 7:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 7a e1 60 00 00 f0 00
blk_update_request: critical medium error, dev sdc, sector 8053088
sd 7:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 7:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current]
sd 7:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
sd 7:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 7a e1 00 00 00 08 00
blk_update_request: critical medium error, dev sdc, sector 8052992
Buffer I/O error on dev sdc3, logical block 394064, async page read

--- End code ---
Quick test

--- Code: ---dd of=/dev/null if=/dev/sdc3
dd: reading '/dev/sdc3': Input/output error
3152512+0 records in
3152512+0 records out
1614086144 bytes (1.6 GB) copied, 1521.2 s, 1.1 MB/s

--- End code ---

Thanks god, I also saved all those files in DVD-ram cartridges and even a copy on an hard-disk, which are all in perfect working condition.

Not a single file was lost.

Moral of the story: don't trust USB-sticks!

james_s:
Based on a sample of just two that you bought 11 years ago?

I've had dozens of USB sticks over the years, so far I've never had a single one of them fail. They're as reliable as just about any other consumer storage.

evb149:
True, but also the same can be said of spinning disc drives and SATA/NVME SSDs.

I have had SSDs as well as spinning disc drives go from working fine to completely unusable in both cases of either instantly totally broken or instantly corrupted / impaired to the point where only some data could be read and nothing more reliably written.

Yeah I know about NAS devices and RAID and so on, but I am literally amazed that none of the mainstream
manufacturers of storage drives basically encapsulate RAID1 or RAID3 level kinds of protections right into the
"unit" of a single storage device to any level of protection.

For instance for complete redundancy yeah you may need 100% physically separate devices, but it'd certainly be possible to share
an enclosure, connector, even the controller but to internally stripe / mirror / parity encode data across physically different
NAND flash chips or physically different heads / platters so that a fault at the single FLASH IC level or single head or single platter
level would not necessarily cause data loss due to either mirroring or parity and redundancy striping.

And in either case the devices could at least add enough checksums / hashes so you can have reasonable confidence that the data you
supply is the data you read back as opposed to some silently corrupted version.

I don't see how it is even SANE to have multi-terabyte level storage so "inexpensive" and ubiquitous these days but to have the
drives themselves have basically no integrated integrity validation exposed to the user and no integrated redundancy options exposed to
the user that operate within the bounds of each individual device.

Then it would be easier to have the user if they want complete redundancy add a second level of RAIDing across two or more distinct
devices or storage systems on top of whatever base line is in the devices.

wraper:

--- Quote from: DiTBho on April 11, 2022, 07:00:52 am ---Back to 2011, I bought a couple of usb-sticks from Amazon, TDK and Sandisk brand new sticks, supposed to be "decent quality" for a kind of backup kind of backup you carefully store inside a locker and don't touch for years.

--- End quote ---
And here is your mistake. NAND cells discharge over time and in case of MLC, TLC, QLC it becomes hard to distinguish actual data within the cell as basically it's stored in analog voltage levels. For long term storage you need SLC flash, or one which is rewritten from time to time (decent SSD do this automatically). Type of error correction used and if it can adjust to diminishing voltage levels matters a lot too. I have even worse, Patriot 64GB SD card purchased about 10 years ago which starts corrupting the data after about 1.5 years.

DiTBho:

--- Quote from: james_s on April 11, 2022, 07:05:20 am ---Based on a sample of just two that you bought 11 years ago?

--- End quote ---

Based on several similar episodes happened in the last eleven years.

Just, if in the other cases I have used and handle without care the USB that I brought around - and you think - ups, doesn't it no more work? d'oh, must be your fault - in this case the two sticks were securely stored in a locker for years.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version