USB flash capabilities

Cost and density rule the memory stick world. So a lot of time-wasting tricks must be used to make flakey chips sellable.

Why not use regular SSDs?

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

First off, does it matter? The customer is waiting, not you.

Write speeds depend on the device, (more expensive is faster) write pattern (sequential is faster, random is slower) Device history (first writes are faster than re-writes)

If it's critical, simply include a new thumb drive with good

Or, put a vending machine with suitable devices nearby.

bob prohaska

There's a difference between using a removable medium as a "transportation mechanism" (to move data to someplace else) and as an actual mounted volume. Imagine replacing the disk drive in your PC with a USB thumb drive.

It's not just that the user is waiting but, rather, that the device's performance may not be suitable for the task to which it is being applied.

E.g., imagine capturing broadcast video onto that medium; if it's "average" throughput can't keep up with the rate the data is sourced, then the operation will fail.

Of course. But, with thumb drives, the user is often not savvy enough to know that he has made a bad device choice -- until it fails to meet the requirement (at which point, the data to be captured may no longer be available -- see above example)

I use USB thumb drives as the "system disk" in many of my workstations. But, the filesystems are typically R/O save for special cases that occasionally need update (e.g., /etc is R/W -- but I know better than to write to it aggressively; /var has a tmpfs mounted on top of it so the media never sees the writes; etc.)

Exposing an eSATA interface would likely less expose the user to his own "bad choices". But, it also restricts him to finding -- and mating -- a SATA drive (rust or solid state). Less convenient than a thumb drive (or even an "external USB disk")

Using "camera media" (SD, microSD, xD, memorystick, etc.)

If you bought your PC and were given *a* thumb drive to use with it, how long before you would misplace it,

The interface is just *too* ubiquitous. And, the devices sold to mate with it are all over the map (in terms of performance, reliability, etc.)

Don Y snipped-for-privacy@foo.invalid wrote: |--------------------------------------------------------------------| |"On 3/13/2026 8:26 PM, snipped-for-privacy@www.zefox.net wrote: | |> Don Y snipped-for-privacy@foo.invalid wrote: | |>> I'm toying with the idea of letting users mount USB drives | |>> as live volumes (not just for "data transport"). | |>> | |[. . .] | |>> | |>> I tried some larger thumb drives (as you KNOW that's what users | |>> are going to think when it comes to "USB drives") and the | |>> performance is all over the map! | |>> | |[. . .] | |>> | |>> I guess I could query the device and/or only support "approved" | |>> devices. But, that is likely going to meet with disdain as | |>> users complain that "their" device isn't on the list of supported| |>> devices ("Why not?")" | |--------------------------------------------------------------------|

Dear Don Y:

Of course they would disdain.

|--------------------------------------------------------------------| |">> | |>> Perhaps the only realistic approach is to use such devices solely| |>> for "off-line" work? | |> | |> First off, does it matter? [. . .]" | |--------------------------------------------------------------------|

Of course it matters.

|--------------------------------------------------------------------| |"There's a difference between using a removable medium as | |a "transportation mechanism" (to move data to someplace | |else) and as an actual mounted volume. [. . .] | |[. . .] | | | |It's not just that the user is waiting but, rather, that | |the device's performance may not be suitable for the task | |to which it is being applied." | |--------------------------------------------------------------------|

I recommend against USB media. Whether an operating system or the power supply thru a USB port is flaky (cf. what Jin Larkin wrote, but he blamed chips), something screws a USB thumb drive (of various manufacturers; of various sizes; and of various years) long before a maximum limit of flash writes could become a problem.

Elsewhere in this thread there is a mention of SSDs.

This webpage says: "SSDs and internal hard disks are preferable to DVDs and CDs."

However a comment in a recent LinkedIn thread alleges that a new SSD stopped working.

I am thinking about making additions to this webpage, e.g. by mentioning a product by Logikhaus Pte. Ltd. ( HTTPS://WWW.Logik.Haus ). However, that product is not actually shown on Logikhaus's website yet. Corrections; contradictions; improvements; and other additions for this website are welcome.

|--------------------------------------------------------------------| |"[. . .] | | | |[. . .] But, with thumb drives, the user is often | |not savvy enough to know that he has made a bad device | |choice [. . .] | |[. . .] | | | |[. . .]" | |--------------------------------------------------------------------|

An ordinary user knows to unmount a USB thumb drive but dangerously yanks it out without unmounting. (S.

John Larkin snipped-for-privacy@glen--canyon.com wrote: |---------------------------| |"Why not use regular SSDs?"| |---------------------------|

A thread on LinkedIn contains comments by 2 commenters which allege that SSDs fail. Petr Dvořák created that thread on February 22nd,

Recall, USB is just an interface; it doesn't MANDATE a particular type of storage media.

E.g., I have many "external USB disks" (spinning rust) that don't suffer from the bandwidth or durability issues that plague flash drives.

The problem is one of expectations; you put a USB port on a product and people want to plug in a thumb drive.

And, people have a "the-bigger-the-better" mentality -- esp when "bigger" is often seen as more economical (bits per unit cost). Not realizing, of course, that bigger *thumb* drives are usually less robust devices (TLC, QLC) than their smaller ancestors (SLC).

I'm not concerned with COTS "consumer devices" as this is my own hardware (and software) -- as well as "process" (e.g., no "click here to remove device").

There will always be the potential for a race between process and user actions with a removable device, regardless of interface. E.g., eSATA, Firewire, USB. memory card, etc. can all be removed at inopportune times.

The quality of an SSD can vary from manufacturer to manufacturer, model to model, date-of-manufacture to date-of-manufacture, etc. Historically, some have been plagued with buggy firmware (there have even been reports of "secure erase" not working :> )

The extent to which an SSD is over provisioned will go a long way towards representing its durability. But, a miserly user who "overuses" a single (low end) device will eventually complain when it fails.

My use pattern differs from typical in that I am not using it as a secondary R/W store. Rather, using it as "offline storage" despite being connected.

E.g., imagine having collected some "data" that the user would like to transport *from* your device. Perhaps to store offline. Or, to transfer to another device where it can be consumed.

The traditional way of doing so is to *copy* (or "move") said data from internal storage to an external device. This can happen at whatever rate the user is willing to afford -- if he is willing to wait, then he can use a slow drive.

Because the data is present "internally", one can design a protocol that doesn't risk data loss -- ensure ALL of the data has been copied before deleting the original.

But, that requires internal storage capable of holding all of the data (plural) until (and in case) the user decides to offload it. Imagine your camera having to store EVERY photo the user might want, indefinitely; there is only one chance to save the data (as the subject of the photo can move or disappear after the shutter has been activated).

So, you have to be able to store at least one complete frame while writing to the medium. (imagine recording moving video!) You also want to be able to write that to the media fast enough that the user doesn't complain about how quickly he can take the NEXT photo.

There are other products that expect the storage medium to be "available" and reliable lest their entire purpose be at risk (e.g., data loggers observe "current conditions" so expect the medium to capture those NOW as the conditions WILL change)

That has always been a problem as long as we have had removable media. One never knows, for sure, when it is "appropriate" to remove said medium unless advised by the system that is using it.

I built a CP/M machine, ~50 years ago, that used a large RAM disk as a cache, deferring actual writes to the magnetic media. As there was always the risk of the user removing that medium prior to flushing the data to it, I selected drives (8" floppies!) that had the ability to lock their doors/eject mechanisms. I.e., the user couldn't physically remove the medium until he *asked* the system to unlock the door. Of course, that provided a natural point for the system to determine which data was "dirty" and flush it as appropriate. THEN unlock the door.

The USB problem is related to its ubiquity; users THINK all USB devices are the same and aren't savvy enough to know how to choose (and maintain) "good" ones.

Don Y snipped-for-privacy@foo.invalid wrote: |-----------------------------------------------------------------------| |"> I recommend against USB media. Whether an operating system or the | |> power supply thru a USB port is flaky (cf. what Jin Larkin wrote, but| |> he blamed chips), something screws a USB thumb drive (of various | |> manufacturers; of various sizes; and of various years) long before a | |> maximum limit of flash writes could become a problem. | | | |Recall, USB is just an interface; it doesn't MANDATE a particular | |type of storage media. | | | |[. . .]" | |-----------------------------------------------------------------------|

True. I do not detect these problems with SATA (hard disks); EIDE (hard disks); game-console cartridges; floppies; C.D.s; DVDs; the Internet; and 8-bit-home-computer 'audio' tapes. We did detect these problems with all the USB storage media that we tried, e.g. hard disks.

|-----------------------------------------------------------------------| |"E.g., I have many "external USB disks" (spinning rust) that | |don't suffer from the bandwidth or durability issues that | |plague flash drives." | |-----------------------------------------------------------------------|

We find external USB hard disks to be much worse than USB flash sticks.

|-----------------------------------------------------------------------| |"[. . .] | | | |The quality of an SSD can vary from manufacturer to manufacturer, | |model to model, date-of-manufacture to date-of-manufacture, etc. | |Historically, some have been plagued with buggy firmware | |[. . .]" | |-----------------------------------------------------------------------|

I use a few SSDs but I do not have much experiences with SSDs yet. So I do not know much about them. I welcome insights or even ancedotes. (S.

I find thumb drives "wear" a lot more noticeably than disks. E.g., I have a 64G, USB3 thumb drive that has dropped from ~50MB/s to 25MB/s despite very little use.

I now put ~500G SSDs in external (USB3) cases and use them in place of thumb drives for increased capacity, throughput and durability. Thumb drives have been relegated to "write once" type applications (e.g., read instead of write).

I was an early adopter and got burned; spinning rust seems to degrade more gracefully than SSDs.

In a (Windows) PC, it's hard(er) to control where writes occur. So, I avoid them on all but *BSD machines. There, I can deliberately structure the filesystem to channel writeable objects into places where I can place more mutable storage and rely on the bulk of the store to be R/O.

I treat the drive as just blocks of (slow) memory in the VMM system. I don't "respect" anything that may have existed on it prior to "mounting".

So, to the software accessing it, it just looks like a chunk of memory that is typically accessed sequentially. The pager backing it ensures the blocks get laid down in a particular order. Then, when the "object" is closed, it is appropriately "decorated" to make it look like a "real file" (instead of a set of blocks on a "disk")

Similar to how you WRITE an optical medium.

What's important is that writes don't fail and that they have predictable throughput as there's nothing really buffering writes *behind* the drive (it's just "memory", after all).

I would have to do a "test/qualification run" prior to actual use. And, hope the performance doesn't degrade between that point and the actual use.

You would likely have to test as much of the "drive" as you expect to use of it as testing a few blocks makes no guarantee as to the performance the LAST (in time) block will exhibit.

In the days of 4G drives, this might be acceptable. But, nowadays, folks don't hesitate to use REALLY big flash drives (e.g., large fractions of a terabyte). Such a "test run" would be time consuming and, for "cheap" drives, might impose too much wear on the media.

I'm not sure how good a predictor TBW is of durability. And, of its correlation with *performance*.

Yes. SWMBO uses them as substitutes for DVDs (copying various "videos" onto a drive, labeling it as such and then READING it as often as she wants). I use them as bootable drives in most of my servers as you can put a full system an a 8-16GB drive, leaving all of the spindles available for other uses.

But, most of these machines have oodles of RAM so I can create tmpfs atop any parts of the filesystem that need to be updated often (e.g., /var). This both improves performance (access to tmpfs is much faster than physical media) and avoids the wear issue.

(The downside being any crash leaves you without a /var/log of events leading up to it!)

Yes. I had an SSD just *stop* on me. No "degradation" just total failure.

As I buy things in duplicate, I was not completely surprised when its mate similarly died. No doubt an early firmware issue... I don't expect to need to fix bugs in storage media!! <frown>

Now, I just put SSDs in external cases and use them as big thumb drives. And, know to COPY files and not MOVE them (until I know they have attained their ultimate destination). If it fails, <shrug>

The problem is that the USB interface is just too damn convenient! E.g., I could use an eSATA interface to bias towards the use of "better" storage devices. But, now you have something big, cabled and "externally powered".

I'm presently exploring memory cards to see if they are more reliable (or, at least, better *characterized*). But, that format doesn't seem to be anywhere near as ubiquitous...

NVMe M.2 modules seem to have a particularly clean interface as well as being very fast. John

But, do they make a "portable" form -- other than packaging them inside a "USB case"? I've only seen them as things that you *install* inside a computer case -- not something intended to be easily installed/removed.

That's the appeal of USB (as an interface). But, also its downside (as all sorts of *crap* can easily support a USB interface).

"Memory cards" aren't quite as ubiquitous but are designed to be easily (and repeatedly) removed.

Imagine swapping SODIMMs (or M.2s) as often and as easily as USB devices; when does the physical interface crap out?

Of course they fail - Spinning rust fails. Everything fails eventually. The question is , what is their expected lifetime and does that fit your requirements?

Jim Jackson snipped-for-privacy@Franjam.org.UK> wrote: |------------------------------------------------------------------------| |"Of course they fail - Spinning rust fails. Everything fails eventually.| |The question is , what is their expected lifetime" | |------------------------------------------------------------------------|

A contributor to that thread seems to allege that an SSD fails since its 2nd day of operation. (Perhaps I read too much into his usage of English as a lingua franca.)

|------------------------------------------------------------------------| |"and does that fit your | |requirements?" | |------------------------------------------------------------------------|

That SSD failure does not fit that contributor's requirements. (S.

The problem with SSDs is their failure is tied not to PoH but to the amount of data written.

I have rust drives with 50K PoH that still don't claim any bad sectors.

But, I can "wear out" an SSD in a fraction of that *time* just by mounting it as swap, etc.

You need to understand the *type* of use and not just the amount of use. I can recall early EAROM devices with 10^4 (!) write cycles. Software written assuming the devices were BBSRAM would kill them in a matter of minutes!