Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Is it possible for (Debian) Linux to kill an SSD?

Need help with peripherals or devices?
Message
Author
Auvo
Posts: 36
Joined: 2010-08-16 13:23

Is it possible for (Debian) Linux to kill an SSD?

#1 Post by Auvo »

Few days ago, while I was upgrading my system (via apt upgrade), it started giving some errors. Can't remember accurately, but things like "can't do operation X because /path/to/the/file/Y is missing. I didn't have time to save those error messages, so this is basically only what I managed to read. After that the upgrade process stopped because of errors. Meanwhile, the panel and all other objects disappeared from my desktop. The frame of terminal window also disappeared and terminal froze, so I wasn't able to type anything. I switched to command line, which kinda worked but all the commands I tried, returned like "command not found" or so. Shortly after that it started to show error messages, can't remember those either but something that sounded critical. I couldn't do anything else, so I rebooted, and while I was already sure that it won't boot anymore, I still got surprised because the machine said there is no disks to boot from. Like, no disks at all. I checked from BIOS, which also didn't recognize that SSD at all anymore. So I took off this SSD and plugged it to another computer via usb. Windows machine seems not to recognize anything when plugged in. Debian machine recognizes at least something, this is from dmesg:

Code: Select all

[ 5006.876545] sd 8:0:0:0: [sdd] Read Capacity(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 5006.876550] sd 8:0:0:0: [sdd] Sense not available.
[ 5006.876556] sd 8:0:0:0: [sdd] 0 512-byte logical blocks: (0 B/0 B)
[ 5006.876559] sd 8:0:0:0: [sdd] 0-byte physical blocks
[ 5006.876570] sd 8:0:0:0: [sdd] Write Protect is off
[ 5006.876574] sd 8:0:0:0: [sdd] Mode Sense: 00 00 00 00
[ 5006.876580] sd 8:0:0:0: [sdd] Asking for cache data failed
[ 5006.876584] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[ 5006.876988] sd 8:0:0:0: [sdd] Read Capacity(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 5006.876994] sd 8:0:0:0: [sdd] Sense not available.
[ 5006.877008] sd 8:0:0:0: [sdd] Attached SCSI disk
[ 5027.019800] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[ 5027.050237] usb 4-1: New USB device found, idVendor=174c, idProduct=1153, bcdDevice= 0.01
[ 5027.050244] usb 4-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 5027.050247] usb 4-1: Product: AS2115
[ 5027.050250] usb 4-1: Manufacturer: ASMedia
[ 5027.050253] usb 4-1: SerialNumber: 00000000000000000000
[ 5027.051923] usb-storage 4-1:1.0: USB Mass Storage device detected
[ 5027.052134] scsi host8: usb-storage 4-1:1.0
[ 5028.064562] scsi 8:0:0:0: Direct-Access     ASMT     2115             0    PQ: 0 ANSI: 6
[ 5028.099929] sd 8:0:0:0: Attached scsi generic sg4 type 0
[ 5028.101757] sd 8:0:0:0: [sdd] Spinning up disk...
[ 5149.260097] sd 8:0:0:0: [sdd] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 5149.260106] sd 8:0:0:0: [sdd] Sense Key : Not Ready [current] 
[ 5149.260110] sd 8:0:0:0: [sdd] Add. Sense: Logical unit is in process of becoming ready
[ 5149.260116] sd 8:0:0:0: [sdd] 0 512-byte logical blocks: (0 B/0 B)
[ 5149.260119] sd 8:0:0:0: [sdd] 0-byte physical blocks
[ 5156.209253] sd 8:0:0:0: [sdd] Test WP failed, assume Write Enabled
[ 5163.158511] sd 8:0:0:0: [sdd] Asking for cache data failed
[ 5163.158519] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[ 5163.161618] sd 8:0:0:0: [sdd] Spinning up disk...
But Debian also didn't really recognize (or mount) the disk. So I abandoned this SSD and bought new one. Reinstalled Debian and now everything is working again. Even better, because that old SSD was a little bit too small, so now I got a reason to upgrade it. Also I haven't any important files saved on that computer, so this was not a big loss. So the question, finally:

Is it possible for Debian (or any other operating system) to break the disk so completely that it doesn't get recognized anymore? This question includes things the user can do from software side. I know that it's possible to break the filesystem (actually have done that) so the machine doesn't boot anymore, but usually you just format that disk and reinstall. Haven't seen or heard this kind situation before. I'm not blaming Debian for this, so the question is that should I blame myself, or the SSD? I'm just curious what possibly happened, because I have no way to investigate it.

If it matters, the machine is 5-10 years old Acer laptop, and that SSD was OCZ Vertex 60Gb. The disk had perhaps been used like 3 years before it died. My system is Debian Buster.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#2 Post by bw123 »

I haven't killed an ssd yet. I'm only on yr two of the three yr warranty on my first, a sandisk ssd plus.

I think it's possible they can get fouled up like spinning disks. I have killed dozens of IDE drives in the past. I used to take them out and slowly zero fill them in an old reliable desktop pc I kept just for diagnostics and stuff. I don't think that would work on an ssd, the more writes you do the worse they likely get. Did you keep a record of any S.M.A.R.T. self tests, or hours of use or other data on it?

Maybe if that happens to me I'll try the mfgr drive diagnostic software, if they even provide that anymore.
resigned by AI ChatGPT

Bulkley
Posts: 6384
Joined: 2006-02-11 18:35
Has thanked: 2 times
Been thanked: 39 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#3 Post by Bulkley »

You are not the first.
SSD is dead, this issue is well known and plagued the vertex 2 drives.
From Tom's Hardware.

Auvo
Posts: 36
Joined: 2010-08-16 13:23

Re: Is it possible for (Debian) Linux to kill an SSD?

#4 Post by Auvo »

bw123 wrote:Did you keep a record of any S.M.A.R.T. self tests, or hours of use or other data on it?
No I didn't. But I'd say that the machine is in daily use, although mostly playing Spotify to my home stereo.
Bulkley wrote:You are not the first.
SSD is dead, this issue is well known and plagued the vertex 2 drives.
Interesting. So seems like it should be a hardware issue. Though I have done some quite fishy things on that machine, including use of weird package sources and using Ubuntu's packages sometimes. So I wouldn't be very surprised if there had been something messed up in that system. But everything worked normally before this happened. So there is basically a chance that doing apt upgrade triggered something that I had broken earlier. But do you think that is possible, to completely break the disk from the os? If not, I can just blame OCZ for this. My new is is from Kingston cheap series.

Bulkley
Posts: 6384
Joined: 2006-02-11 18:35
Has thanked: 2 times
Been thanked: 39 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#5 Post by Bulkley »

Now that you have replace that drive have you tried to access it with any tools? As you said, when you plugged it into a Windows machine it didn't recognize it. Can you format the drive and put files on it? Put a movie on it? Can you use it for non-critical storage? Or is it toast?

User avatar
sunrat
Administrator
Administrator
Posts: 6412
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 116 times
Been thanked: 462 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#6 Post by sunrat »

It's possible for SSDs to fail but failing while being used does not necessarily mean the system using it caused the failure, could be coincidental.
I'm using an OCZ Vertex2 120GB SSD currently which I bought in 2011 IIRC. No issues ever (touch wood :) ).
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!

Auvo
Posts: 36
Joined: 2010-08-16 13:23

Re: Is it possible for (Debian) Linux to kill an SSD?

#7 Post by Auvo »

Bulkley wrote:Now that you have replace that drive have you tried to access it with any tools? As you said, when you plugged it into a Windows machine it didn't recognize it. Can you format the drive and put files on it? Put a movie on it? Can you use it for non-critical storage? Or is it toast?
Windows machine doesn't recognize at all (at least nothing happens in GUI when I plug it, command line work on Windows is totally outside of my knowledge). On my desktop Debian, I get that dmesg output (which I posted in my first message), but at least it doesn't mount automatically. Looks like the machine recognizes it as sdd, but no partitions. So it doesn't appear in /media. I have no skills to do any further investigation, but if you have any ideas how to try access from terminal, please let me know. Otherwise I'd say it is a toast.

dibl
Posts: 528
Joined: 2009-10-13 19:50
Location: Dayton, Ohio, USA

Re: Is it possible for (Debian) Linux to kill an SSD?

#8 Post by dibl »

Tons of information on this topic is available on the internet:

https://www.techrepublic.com/article/ho ... -in-linux/

https://wiki.archlinux.org/index.php/Solid_state_drive

In particular, the default ext4 journal is set to write to the drive that the OS is installed on every 5 seconds. If you think about the number of writes in several years of 24/7 uptime, you can see what might happen to a lot memory cells on a ssd. Booting with a "commit=120" or 360 or whatever your risk tolerance will stand is a way to slow down the wear. Also mounting /var/tmp, var/spool, and other "temporarily needed" directories as tmpfs will spare the ssd some beating.

The newer ssds have considerably improved mtbf specs over the ones from 3+ years ago.
Debian sid / siduction KDE

User avatar
debiman
Posts: 3063
Joined: 2013-03-12 07:18

Re: Is it possible for (Debian) Linux to kill an SSD?

#9 Post by debiman »

Auvo wrote:But I'd say that the machine is in daily use, although mostly playing Spotify to my home stereo.
using a closed-source gui online media player inside a full graphical desktop, non-stop, isn't exactly light usage.
spotify probably performs diagnostics and downloads stuff (and saves it to disk) all the time, even when it isn't playing anything.

not saying that's what caused your problem, just to get things into perspective.

Auvo
Posts: 36
Joined: 2010-08-16 13:23

Re: Is it possible for (Debian) Linux to kill an SSD?

#10 Post by Auvo »

dibl wrote:Tons of information on this topic is available on the internet:
Well, not exactly the topic. I'm aware of SSD's limitations, and I know they have quite short lifespan. So it's possible that my SSD just came to end of it's life. But my original question was that is there other reasons that could possibly cause premature death of an SSD. But you're right; I should do (and should have done) TRIMs. Can't say if it had saved this disk, but I have some other SSDs in my desktop computer, and I haven't ever used TRIM.
debiman wrote:using a closed-source gui online media player inside a full graphical desktop, non-stop, isn't exactly light usage.
spotify probably performs diagnostics and downloads stuff (and saves it to disk) all the time, even when it isn't playing anything.
This is also true.

Seems like everybody here suggest that my SSD just came to end of it's life. Due to it's age, absence of TRIM, or being faulty OCZ Vertex. So I think I can close this case. Thanks for everybody!

CwF
Global Moderator
Global Moderator
Posts: 2639
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#11 Post by CwF »

Auvo wrote:Windows machine doesn't recognize at all (at least nothing happens in GUI when I plug it, command line work on Windows is totally outside of my knowledge). .
If the bios sees it and windows gui does not then use fdisk in a prompt to reclaim the disk.

I have multiple SSD's with 20k hours, one with 39,000 hours of uptime. I have a few cheaper ones that barf every so often for unknown reasons, under debian, but I think it's a crappy firmware issue. All over 20k hours are samsungs.

I've typed a few times that living at 10.5k' hard disk and power supplies fail on a regular basis. I've lost every IDE or consumer sata I've ever bought. Ancient scsi's seem to be eternal. For noise I started buying ssd's a decade ago, IMO a modern quality SSD will outlive any consumer spinner. Frankly I don't think they need any special attention or configuration at all.

Auvo
Posts: 36
Joined: 2010-08-16 13:23

Re: Is it possible for (Debian) Linux to kill an SSD?

#12 Post by Auvo »

CwF wrote:If the bios sees it and windows gui does not then use fdisk in a prompt to reclaim the disk.
Bios also didn't see it while it was installed in the laptop. I was too lazy to install it to my desktop pc, but tried to connect it via usb using external hard drive case. Actually I didn't check if it was seen by bios, but both Windows and Debian refused to boot when the usb drive was connected to the computer. So I gave up.
I have multiple SSD's with 20k hours, one with 39,000 hours of uptime. I have a few cheaper ones that barf every so often for unknown reasons, under debian, but I think it's a crappy firmware issue. All over 20k hours are samsungs.
Interesting. I have used OCZ's and Kingston's SSDs, and this OCZ was my first SSD to break. I have broken some traditional HDDs though. But I'll consider buying Samsung when I need next one.

L_V
Posts: 1477
Joined: 2007-03-19 09:04
Been thanked: 11 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#13 Post by L_V »

Some key points I have in mind for SSD:

★ reserve at least 10% totally free space on SSD (= no partition)
★ don't use swap if not needed (can be disabled in fstab)
★ if swap is really needed, then reduce swapiness (see /etc/sysctl.conf configuration / vm.swappiness=1 for example)
-> current swapiness value given by "cat /proc/sys/vm/swappiness"
★ browser cache should use memory instead of SSD (a bit more complex to put in place).
★ some BIOS important clues: https://forum-en.msi.com/faq/article/id ... ed-to-know
In your BIOS, your SATA controller has selectable modes of operation. Typically these are:
IDE - In this context, it simply means to use 'legacy' ATA operation mode. It can also be referred to as 'IDE emulation', which itself is misleading, as explained earlier, all SATA drives are themselves IDE devices. For using multiple independent drives, this mode of operation can be selected. Note there is no performance 'loss' using this.
RAID - This sets the SATA controller to operate in RAID mode. This is where you would use multiple drives as one single storage 'array'.
AHCI (where supported) - This sets the SATA controller to operate in AHCI mode. It provides 'hot-swapping' facilities, as well as Native Command Queuing will improve the performance.
fstrim.timer should be enabled

Code: Select all

systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) 
No problem by now with a SanDisk (about 3 years old), using ext4.

Segfault
Posts: 993
Joined: 2005-09-24 12:24
Has thanked: 5 times
Been thanked: 17 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#14 Post by Segfault »

> Using EXT4

Why not F2FS?

L_V
Posts: 1477
Joined: 2007-03-19 09:04
Been thanked: 11 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#15 Post by L_V »

1 - because F2FS seems unknown by classical partition tools (at least by default ; libf2fs5 / f2fs-tools to be installed)
2 - don't know if F2FS is safely recommended for SSD
3 - Is Debian proposing F2FS during installation ? (I don't remember that)
4 - never had problems with ext4
5 - I don't use Grub2, but it seems GRUB does not support F2FS => https://wiki.archlinux.org/index.php/F2FS
6 - F2FS vs EXT4 test by xda is not so convincing: https://www.xda-developers.com/f2fs-put ... inst-ext4/

To be investigated.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#16 Post by p.H »

all SATA drives are themselves IDE devices
Bullshit. IDE is Parallel ATA.
L_V wrote:★ reserve at least 10% totally free space on SSD (= no partition)
You can also create a partition to mark the space as reserved and not use it. Note that SSDs already provide overprovisioning, as much as 10% on some models. SSD space is still expensive, don't waste it uselessly. Also, it is reported that ext4 works better with at least 10% free space, so it may be better to set 10% reserved space in the filesystems than reserve 10% of the raw SSD space.
L_V wrote:★ don't use swap if not needed (can be disabled in fstab)
Even when swap is enabled, it is not used (or marginally) when not needed.
L_V wrote:★ browser cache should use memory instead of SSD.
If you mean to store browser cache into tmpfs, it is advised to enable swap when using tmpfs.
L_V wrote:F2FS seems unknown by classical partition tools (at least by default)
What are you calling "classical partition tools" ? fdisk does not care about the filesystem type.
L_V wrote:don't know if F2FS is safely recommended for SSD
F2FS was primarily designed for flash block devices such as USB pendrives or SD cards with "dumb" flash translation layer (FTL). SSDs have advanced FTL which already does what F2FS does (and more) and should not benefit much of F2FS. However it supports TRIM/discard so can be safely used on SSD.
L_V wrote:Is Debian proposing F2FS during installation ?
No, the Debian installer does not support F2FS.
L_V wrote:it seems GRUB does not support F2FS
Indeed, so /boot cannot be on F2FS with GRUB.

Note also that the default initramfs generator does not include the f2fs module (and its softdeps) by default, so if you want / on F2FS, you must add them in /etc/initramfs/modules.

Segfault
Posts: 993
Joined: 2005-09-24 12:24
Has thanked: 5 times
Been thanked: 17 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#17 Post by Segfault »


p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#18 Post by p.H »

This is good news. However the GRUB version in the current Debian stable release "stretch" does not support F2FS yet. Hopefully in the next stable release.

L_V
Posts: 1477
Joined: 2007-03-19 09:04
Been thanked: 11 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#19 Post by L_V »

Grub2/F2FS support looks like a minor issue as long as F2FS is not proposed during installation process, even by Netinstall "expert mode" (at least for test purpose for those not using Grub2).
Would be eager to know how many Debian users currently use F2FS for their Debian system on SSD.

BTW, the main question is .... : is F2FS a real added value for SSD ?
→ not so convincing as seen previous page ( http://forums.debian.net/viewtopic.php?p=680531#p680531 )

More generally, would be good to identify what are the "official" configuration Debian recommendations for SSD (very likely need to be updated).
https://wiki.debian.org/SSDOptimization ... timization

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Is it possible for (Debian) Linux to kill an SSD?

#20 Post by p.H »

L_V wrote:Grub2/F2FS support looks like a minor issue as long as F2FS is not proposed during installation process, even by Netinstall "expert mode" (at least for test purpose for those not using Grub2).
I disagree. The Debian installer is not the only way to install a Debian system.
You can copy an existing installation to F2FS and do the necessary adjustments in fstab, initramfs and boot loader by hand. This is what I did.
You can also use debootstrap to install directly on F2FS.

But the lack of support by GRUB forces to either
- use a boot loader supporting F2FS (I don't know any)
- use a filesystem-independent boot loader such as LILO which relies on static file-to-block mapping. However I would not trust it on a log-structured filesystem even though f2fs seems to allow file mapping (unlike nilfs2, another log-structured filesystem which is supported by GRUB)
- or put /boot on a separate filesystem type supported by the boot loader, which seems the only reliable option to me.

Post Reply