For interesting topics. But remember this is a Linux Forum. Do not post offensive topics that are meant to cause trouble with other members or are derogatory towards people of different genders, race, color, minors (this includes nudity and sex), politics or religion. Let's try to keep peace among the community and for visitors.
No spam on this or any other forums please! If you post advertisements on these forums, your account may be deleted.
Do not copy and paste entire or even up to half of someone else's words or articles into posts. Post only a few sentences or a paragraph and make sure to include a link back to original words or article. Otherwise it's copyright infringement.
You can talk about other distros here, but no MX bashing. You can email the developers of MX if you just want to say you dislike or hate MX.
m_pav wrote: Mon Apr 07, 2025 9:27 pm
...
I used to be that way too, but a spinning platter controller can fail just as easily as SSD and I have seen incidences where that has happened in my nearly 30 years of doing this stuff. I think from memory, this is the 3rd time where I have been personally affected by drive failure. Every other incident was PEBCAK.
Maybe, but only on very very old HDDs. (I have never seen this case)
Problem Exists Between Chair And Keyboard / PEBCAK... mostly if the Hdd fell down on the floor ;-)
Pour les nouveaux utilisateurs: Alt+F1 pour le manuel, ou FAQS, MX MANUEL, et Conseils Debian - Info. système “quick-system-info-mx” (QSI) ... Ici: System: MX-19_x64 & antiX19_x32
They die. Mine all started with i/o errors on boot. I don't have that image doohickey when the system starts, so I could see that happening, filled the log right up. Rebooting made those go away, then next boot they are there again. Completely erratic. That can take a week to a month, and after that.. bye.
Of course YMMV, but there is a reason I chuck stuff in the cloud. I have had backup SSDs die on me before these 4, I find they tend to live less long than the oldie spinners. Why that is.. not a clue. I don't do anything different.
Anyway.. TLDR; they die.
MX-23.6_x64 July 31 2023 * 6.1.0-37amd64 ext4 Xfce 4.20.0 * 8-core AMD Ryzen 7 2700
Asus TUF B450-Plus Gaming UEFI * Asus GTX 1050 Ti Nvidia 535.247.01 * 2x16Gb DDR4 2666 Kingston HyperX Predator
Samsung 870EVO * Samsung S24D330 & P2250 * HP Envy 5030
I just flipped our Studio computer over to two 2TB SSD's last year.. There are literally years of work on there, (yes I do backup when the mood strikes). Now I'm terrified...lol
How do they die? To better understand that, we have to be aware of some of the lesser known elements of their design.
Data stored on a SSD which is never changed is still moved around the drive by the drives firmware to keep its integrity through the drives lifetime. This is done to try to avoid data loss due to electrical charge leakage from the storage media over time because the charge states of each transistor will either represent a 1 or a 0, which are translated to into binary values. Using electrical charge states makes data prone to loss for any number of reasons, such as the SSD's onboard charge capacitors draining to zero or slight manufacturing defects which lead to drain down a charged element. Most quality branded SSD's will have a charge capacitor that can sustain a SSD for up to a year, which is why consumer quality SSD's are only given a 1 year data integrity rating.
In order to keep the drives data fresh, SSD firmware will test the readability of each sector and move its contents out when it detects the possibility of an integrity loss. Using file hashes and redundancy features, it is possible for a mildly altered file to be fully reconstructed during this move, but either way, the unused file has moved to a different storage location which counts towards the endurance statistics. If you have a SSD that's not been connected for a long time, it pays to leave it connected and unused for at least 10 minutes to allow the firmware to do its work.
This is why I have over the last 2 years started to advise customers to get drive sizes that are roughly double what their maximum expected usage value will be. This is what I did with the 2TB SSD in my daily driver and what this post is related to, where at any time, I might have consumed roughly 50% of the drives capacity where in reality, it was more like 60%
So for a drive whose controller does not immediately die as mine did, the evidence is pretty much like @Eadwine Rose said, however, read on to see a real world scenario of a dying SSD I have already spoken of on these forums.
I saved a machine that started generating random errors when saving a file. The users reported it was taking longer than it should have to save files and sometimes threw up an error. For all intents and purposes, the save actions appeared to be normal, but the machine appeared to be "off its game" with unexpected pauses and failures to load up new apps after the file save operation, and that did not provide a good look for a machine with an "alternate OS".
The machine had done it's life in a local council office and was donated for community use so I loaded it with MX and put it into a church to act as a recording station for the meetings held in that building. It was used by many groups, both church and non-church related. I provisioned accounts for the regulars and all others has a guest account on which I placed restrictions. One user, an ex broadcast studio tech would record their meeting with Audacity, save the project with each project weighing in at roughly 2.5 - 3 GB in size and leave it on the machine for later reference "if ever needed" , however he never did anything with his recordings, such is the nature of free use of a machine with scant regard for its continued availability. The SSD was only 128GB and it had already done some time in corporate office use, and the OS and swap partitions occupied 30GB of that. Long story short, that user consumed 55GB of space over 5 months and the drive was getting short on space, hence the save errors. As it turns out, his large files were smashing at the SSD wear leveling algorithms leaving little space for his and others usage.
The SSD firmware was doing all it could to keep files intact with ever decreasing available space and soon enough the SSD pages started to burn as it tried to shift stuff around to increase available space by maximising page usage (SSD's use pages instead of sectors). End result, only a small volume of the pages had died, but the overall endurance suffered much and it lost the fight.
In this case, I could save the machine state by moving all the the user account files to an external drive, make a snapshot-personal saving all that I left in the user accounts and saving the ISO to an external drive. I fitted a new larger SSD, installed the snapshot and returned users data to their profiles so they had no sense of loss.
Mike P
Regd Linux User #472293 (Daily) Lenovo T560, i7-6600U, 16GB, 2.0TB SSD, MX_ahs (ManCave) AMD Ryzen 5 5600G, 32G, 8TB mixed, MX_ahs (Spare)2017 Macbook Air 7,2, 8GB, 256GB SSD, MX_ahs
Would not smartctrl have shown this drive was failing?
*QSI = Quick System Info from menu (Copy for Forum) *MXPI = MX Package Installer *Please check the solved checkbox on the post that solved it. *Linux -This is the way!
No, the drive was showing 89% endurance remaining last time I looked which was 3 weeks prior to it dying. The other stats that might have been of interest were that it had reached a temp of 52°c not long after I first installed it when the laptop did not go to sleep on one occasion when I put it into my Laptop backpack and went for a 163KM (100 miles) drive. That was warmer than it should have been, but not enough to have caused any lasting damage.
It also recorded a number of unsafe shutdowns and crc error checks, but nothing of any great concern that would lead me to a sense of impending doom.
I didn't get a chance to check it on the day it died and try as I might, nothing could get a read on the drive.
Mike P
Regd Linux User #472293 (Daily) Lenovo T560, i7-6600U, 16GB, 2.0TB SSD, MX_ahs (ManCave) AMD Ryzen 5 5600G, 32G, 8TB mixed, MX_ahs (Spare)2017 Macbook Air 7,2, 8GB, 256GB SSD, MX_ahs