does trim on a ssd screw up os'es now?

BW-userx · 05-25-2019, 08:56 AM

This happened twice now, on two different Linux Distors.

I ran trim on my drives, and the first one Void Linux, it basically destroyed my OS to where I just got rid of it and installed Arco Linux, and just a minute ago I ran trim on it and was sitting here doing things then it went black screen little cursor in upper left hand cornet then shut down and running jobs on my sdd partitions whatever systemD does 2 minutes to do them so i walked away and when I cam back it was still doing something to it, another 3 minutes and it just stuck so I forced shutdown, reboot.

image says it fails to unmount drive partitons now. even on a second reboot off cli.

Though this being a second time I got a system crash on a trim to the ssds, it sends a red flag to me.

So I am wondering if anyone knows anything about this phenomena.

this is the script I use

Code:

#!/bin/bash
echo "*** $(date -R) ***"
sudo fstrim -v /
sudo fstrim -v /home
[[ -d /media/data1 ]] && sudo fstrim -v /media/data1
[[ -d /media/ntfs1 ]] && sudo fstrim -v /media/ntfs1

echo "***** END TRIMMING **********"

the only actions being performed on the drives where qbittorrent was doing a check on its files.

the ssd drives are a

Code:

  
  /dev/sdb             CHN NGFFSA2242 2
  /dev/mmcblk0         Disk
  /dev/sda             Samsung SSD 860

sda is the reg ssd
the sdb is a PCIe M.2 ssd.

business_kid · 05-25-2019, 01:52 PM

Do we have valid backups here? Sounds like the time for one.

I would never trim root from root, because files are open and Murphy's Law applies, as well as Mrs. Murphy's Corollary (Don't take my husband seriously - he's a total optimist).

I keep a 'get out of jail free' distro just for this sort of occasion. I have Mint-19.0, and the default install only took 6-7 Gig. Personally, I've a 250G ssd, never run trim, and if you run out of space, you can update your backup, delete the lot, and restore again From a look at your options, my guess is you're trimming too much. In my game (Electronics) rule #1 is: "If it ain't broke, don't fix it!"

What size is your ssd, your partitions? If you get a situation where your backup is 6G and your / is showing 10G, then you have a problem. You probably deserve a slightly larger ssd.

rknichols · 05-25-2019, 02:26 PM

There are known issues with queued TRIM on certain devices, Samsung 8xx SSDs in particular, causing data coruption. Supposedly, that has been fixed in the Linux kernel by blacklisting queued TRIM on affected devices. See https://lkml.org/lkml/2015/6/10/642 and related searches for "fstrim queued" and "fstrim data corruption" (without the quotes).

Another link: https://wiki.debian.org/SSDOptimization

and https://bugs.launchpad.net/ubuntu/+s...m/+bug/1449005 see comment 16.

BW-userx · 05-25-2019, 05:01 PM

Quote:

Originally Posted by business_kid

Do we have valid backups here? Sounds like the time for one.

I would never trim root from root, because files are open and Murphy's Law applies, as well as Mrs. Murphy's Corollary (Don't take my husband seriously - he's a total optimist).

I keep a 'get out of jail free' distro just for this sort of occasion. I have Mint-19.0, and the default install only took 6-7 Gig. Personally, I've a 250G ssd, never run trim, and if you run out of space, you can update your backup, delete the lot, and restore again From a look at your options, my guess is you're trimming too much. In my game (Electronics) rule #1 is: "If it ain't broke, don't fix it!"

What size is your ssd, your partitions? If you get a situation where your backup is 6G and your / is showing 10G, then you have a problem. You probably deserve a slightly larger ssd.

I've never had an issue with running that trim until recently. if I remember correctly Slackware never does/did this, just other ones. I've been in the others one lately. this arcolinux puts discard in the fstab. so does that take presidents over trim?

Code:

[userx@archooo ~]$ sudo fdisk -l 
Disk /dev/sdb: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Disk model: CHN NGFFSA2242 2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3a883dd5

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1  *         2048  80167362  80165315  38.2G  7 HPFS/NTFS/exFAT
/dev/sdb2        80168960  81919999   1751040   855M 27 Hidden NTFS WinRE
/dev/sdb3        81922048 500117503 418195456 199.4G  5 Extended
/dev/sdb5        81924096 164868095  82944000  39.6G 83 Linux
/dev/sdb6       164870144 350214143 185344000  88.4G 83 Linux
/dev/sdb7       350216192 391380991  41164800  19.6G 83 Linux
/dev/sdb8       391383040 500117503 108734464  51.9G 83 Linux


Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x28da7fc5

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1            2048 428099583 428097536 204.1G 83 Linux
/dev/sda2       428099584 976773119 548673536 261.6G  7 HPFS/NTFS/exFAT


Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd09b8eb7

Device         Boot Start       End   Sectors  Size Id Type
/dev/mmcblk0p1       2048 124735487 124733440 59.5G 83 Linux

jefro · 05-25-2019, 09:51 PM

I assume this is still possible.
Not sure what the state is for Linux kernel 5.x
"
WARNING

Some firmware versions on some SSD models have bugs that result in data corruption when used in certain ways. For this reason the Linux ata driver maintains a "blacklist" of certain things it shouldn't do on certain drive/firmware combinations. This list is in the linux source at drivers/ata/libata-core.c. If you have a blacklisted controller/drive combination, you are at risk until a newer kernel avoids the problem. "

https://wiki.debian.org/SSDOptimization

business_kid · 05-26-2019, 04:48 AM

Do I see 204G on / ?

df -h or even the /etc/fstab or /etc/mtab file would give me mount points. I very much doubt if you're short of space, wherever you stuck /. You'll solve this by [U]not[U] running trim.

galen · 06-04-2019, 10:06 AM

don't forget about reserved space
sudo tune2fs -m 0 /dev/sd[drive]
reduces reserved space to 0%
eg.
sudo tune2fs -m 2 /dev/sd[drive]
sets reserved space to 2%

sevendogsbsd · 06-04-2019, 10:25 AM

Been trimming my Samsung 850 Pro SSds for 3 years on both Linux and FreeBSD with zero issues. Haven't run Linux in about 6 months, so can't speak to any recent kernel changes but on FreeBSD, UFS2 on my drives has trim enabled and file systems are healthy.

BW-userx · 06-04-2019, 10:30 AM

I've had to redo everything, format and starting over, and now I am totally gun shy about using trim on anything of my sdd's.

so it does raise a question about discard in fstab.
id it harmful and what does it really do in reference to instead of using trim