Re: Do bootable USB sticks have a date of expiry?
Michael <[email protected]>
| Newsgroups | gmane.linux.gentoo.user |
|---|---|
| Message-ID | <[email protected]> |
On Wednesday, 19 August 2026 13:19:30 British Summer Time Dale wrote: > On 8/18/26 5:07 AM, Michael wrote: > > On Tuesday, 18 August 2026 02:00:15 British Summer Time Dale wrote: > >> Questions. What should a person do to prevent this from happening? > >> Plug the USB stick in on occasion for a few minutes, so it can > >> 'recharge'?? Should one do something else to prevent this? Should > >> one mount the file system? Do something to the files to make them > >> rewrite? > >> > >> The reason I ask, I store backup data on m.2 sticks, USB sticks and > >> such so that if I have a system crash, they would be much needed > >> and > >> quickly. I store them in a fire safe. I usually only plug them up > >> when I need to update them. Since I store things like the world > >> file, passwords that I rarely change, they are not plugged up very > >> often. That said, I also use USB sticks for bootable ISOs as well, > >> like the OP does to it seems. Those can sit untouched for a while. > >> > >> Just curious if there is a way to prevent this. > >> > >> Dale > >> > >> :-) :-) > > > > I've experienced loss of files on USB sticks both with FAT and with > > exFAT filesystems. The directory/file was listed, but I could not > > open it or copy it. Using fsck, app-admin/testdisk and > > sys-fs/ddrescue didn't help. Thankfully, the data loss was not > > critical, but it is annoying all the same. > > > > Generally, M.2/SSD drives and comparatively cheaper USB flash drives > > do not have the same quality of memory cells and definitely do not > > have the same quality of flash controllers. > > > > I read some tests which showed cheap USB/SD/microSD sticks where > > their unsophisticated memory controller performs virtually no wear > > levelling. Really cheap (smaller and older?) USB/SD/microSD sticks > > have no onboard controller at all and rely on the host OS accessing > > directly raw cells on them. These won't last long and age quickly > > if overwritten multiple times. Filesystems like F2FS are meant to > > compensate somewhat for lack of a device controller, but with no > > wear levelling or garbage collection the devices can't last if > > being written to frequently. > > > > In addition, we have SLC, MLC, TLC and QLC NAND cell density > > technologies, storing increasingly more bits per cell. All things > > being equal industrial grade SLC SSDs will last longer than > > discount unbranded QLC equipped drives. This multilevel bit > > storage is not dissimilar in principle to CMR Vs SMR spinning > > drives and their respective longevity. Either way, charge leakage > > from a cell will eventually and inevitably lead to loss of data and > > file corruption. When this moment arrives with SLC the loss of > > data will be more limited than with e.g. QLC. This is why such > > media are not meant for long term storage and they cannot be > > trusted with important data without a higher fidelity backup. > > > > I have read plugging in a USB stick will refresh the charge on the > > device and that should prolong its useful life. Applying power will > > refresh the charge on the controller and this will help to maintain/ > > refresh its flash translation layer (FTL), but I am not sure the > > charge on each flash cell will be refreshed, unless such individual > > cells are re-written. Plugging in a USB/SSD drive and leaving it > > connected is still a good idea, because it will allow for its flash > > controller to perform garbage collection while sitting there idle. > > While it does this it may move cells around and this ought to help > > in part with data retention. > > > > I've had USB sticks which lasted more than 15 years, but they were > > used occasionally and only for data transfer/short term storage. I > > don't think they would have survived more than 5 years if used > > daily. I've had SSD drives in daily use which lasted just over 10 > > years, before the controller died suddenly and all data became > > inaccessible. > > > > Besides anecdotal data survival stories, I consider SSDs to be > > better > > than USB sticks. Spinning (CMR) drives better than NAND cells. > > Paper records in a fireproof box are better than magnetic disks. > > The 3-2-1 backup strategy applies and of course today we also have > > cloud storage (if you can trust them with your data). > > All my storage m.2 sticks are either Samsung or Crucial brand. Samsung SSDs are very good from whatever reviews I have read. Crucial are also a good brand, using Micron NAND chips. I use both brands. Crucial are typically cheaper on a like-for-like comparison, because they use a smaller cache. > They > are placed in a sandwich style case with a USB connector. I do have > those little thermal pads to make sure the heat transfers to the > case. They run pretty cool but I don't usually have them plugged in > to long anyway. The thermal pads & heat spreader are needed for the controller chip. This needs to be kept cool to stop thermal throttling or even failure. However, the memory chips themselves do not need cooling in most hardware setups. They need to reach a normal operating temperature to enable reliable P/E cycles. I added a thermal pad on my M.2 stick along its entire length, but if I were to do it again I would only add a pad at the controller chip - YMMV. Given that garbage collection takes place when the drives are idle, it is a good idea to leave them connected for a while after you finish writing data to them. You won't have to wait for days like with SMRs, but waiting for an hour or two won't cause any harm. > I can get links if you want to see EXACTLY what I > have and which one may need something different than the others. One > says NVME, another says NAND and the other one says HMB. Those are > the things that I see that is different. I also have one in my puter > for the OS as well. No need for links, NVMe (Non Volatile Memory Express) specifies the onboard controller interface, allowing high bandwidth parallel access to the storage media via PCIe. NAND is the type of memory chips on the SSD. I don't think NOR is used for SSDs(?), at least not for retail hardware applications. HMB (Host Memory Buffer) refers to the type of cache used by the SSD. Instead of onboard DRAM (expensive), or SLC cache, or (pseudo) SLC cache, some SSDs borrow a bit of your system RAM to store metadata. It's a way of assisting DRAM-less SSDs to behave like more expensive SSDs with onboard DRAM, albeit slower and with increased latency under high loads. > I took the M.2 sticks out of the safe, plugged them in for a few > minutes, mounted them and kinda clicked around and then unplugged them > and put them back in the safe. I did similar with the regular USB > sticks as well. I get different kinds of USB sticks but usually read > reviews and find someone that has tested the ones they buy and claim > they are good, plus high rated as well. Some of those aren't cheap. Most smaller retail USB sticks do not have an onboard controller to perform wear levelling and garbage collection, so sync'ing and unmounting them after you finish writing on them won't have any adverse effect. Some expensive USB drives have onboard controllers with the necessary algorithm for optimising data storage and longevity. The difference in price between the two types of USB drives points to this, but you can always check the manufacturers specification.
signature.asc
(application/pgp-signature, 870 B)
-----BEGIN PGP SIGNATURE----- iQJPBAABCAA5FiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmqFyucbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwyAAoJELHqqvbClWcZTXgQALHIqqmWMiCR6sRgJFOX ONHDuHFyHRtTyLAT3GHa4pc/BvLGFDZtV+9d6Egy5nyVQuF/5U6QnP/j5LOMv7Zj keoK7URdYS58QPKKjaDiXO0acIl9E8hz9FbUtqeshErY4sfovfcdlippjNxlvlRs zxc5R8cq73oCTxcHye2B93z23nDp8/g5ccKaBnFxUf1w0NjofnpJ0KN2L1/aohZ3 gxFAx4E/9rXf75sLAWFP4bLUEpWeYVxJ03G23iSa3Uf9rdY8o92sOImyNiwF2XjO RLxg2D53sM4iIX8UjDg78SYMdKD4PuMe+jjgPQ/czqG5DcJL4nj+sOKd3l0/5IEs 3pwwcgJ5zvoNZpjJlqiy18XtS9m5ipQ5d5pvND88+2FWAVb6TEjNLsu5sLQ92JWO hzCaKAEXGXxWrrANJPn1Ifxq0cZ547b9gTa3arwoZ6bSExmc89t320EN0To64W2+ 2eAIfgB5Aw0sx90uKGl9/D7yMf0g489yZLdVe7nYlKem72t0V3Baicsw4Xqg4bMy aE+WDP8xWnFoeA7HBVPb4Ric1zPnt6o0oTQ0MciMx27Z6iST3YT39cGP5JUFQzDr 8I/AHg45T1n+aF7v6zkf0V7on3N4RSqRmDMYaQ9O9m2DuT5UjT11jcsORvryW76T yLvbp2B/qKSqp4vdDH6VIEF+ =P7Bh -----END PGP SIGNATURE-----