I am using a new laptop, purchased about two weeks back. It came with an SSD, I cannot seem to figure out how to verify that it has TRIM support and all.
I refer this arch wiki page: https://wiki.archlinux.org/index.php/Solid_state_drive
From the arch wiki
To verify TRIM support, run: $ lsblk --discard
And check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support.
DISC_GRAN and DISC_MAX are non zero for every entry. Does that mean my HDD also supports trim? (I never heard that HDD are supposed to be trimmed.)
Again from the Arch Wiki
Alternatively, installhdparm package and run: # hdparm -I /dev/sda | grep TRIM
Data Set Management TRIM supported (limit 1 block)
The relevant outputs on my laptop
$ sudo hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 10 blocks)
* Deterministic read data after TRIM
$ sudo hdparm -I /dev/nvme0n1 | grep TRIM
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
This also detects trim support on my HDD, and refuses to run on my ssd. Out of this confusion, I haven’t enables fstrim.service. My ssd hasn’t been trimmed even once. Reading from the wiki page, I want “Periodic Trim” and not “Continuous Trim”.
But I’m still confused about all this. I do a fstrim dry run, and it runs on my hdd, not on my ssd. I suppose the opposite should be happening.
$ fstrim -an
/mnt/hd1: 0 B (dry run) trimmed on /dev/sda6
/mnt/hd2: 0 B (dry run) trimmed on /dev/sda7
sda6 and sda7 are ext4 partitions on HDD which are currently mounted. SSD is at /dev/nvme0n1. So I suppose that even when the fstrim.timer runs, it won’t touch my ssd. Rather it will try to do something on the HDD.
Just for reference:
-a, --all trim mounted filesystems
-n, --dry-run does everything, but trim
I have made some changes in bios settings. The only storage related setting I remember changing is that I disabled Intel RST and switched to AHCI. There are battery charge settings I changed, disabled intel turbo boost, disabled bluetooth.
I cannot switch back to Intel RST in the bios, because I suppose it is not easy to dual boot with that enabled. (Linux mint had refused to detect my storage with RST enabled. With AHCI, it worked fine. I didn’t try EnOS with RST enabled.)
As for my fstab, this is how it looks like.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=9864-BC0B /boot/efi vfat umask=0077 0 2
UUID=f1f86514-4df2-422c-8a7a-1ad2b16e1013 / ext4 defaults,noatime 0 1
UUID=f3251a85-d092-4e72-b5ce-d03ab2f888e2 /mnt/hd1 ext4 defaults,noatime 0 1
UUID=860c155d-b387-48d1-ac85-522fb2edc7db /mnt/hd2 ext4 defaults,noatime 0 1
I manually added the last two entries after install. They are 350gb ext4 partitions each, and correspond do /dev/sda6 and /dev/sda7 respectively.
Other partitions on my HDD are ntfs and they are for windows (dual boot system). Never mounted.
I figured out one part of the problem. fstrim -an trims only hdd partitions.
But sudo fstrim -an runs also on ssd.
I am foolish sometimes. Sorry for wasting your time.
sudo fstrim -an
/mnt/hd1: 0 B (dry run) trimmed on /dev/sda6
/mnt/hd2: 0 B (dry run) trimmed on /dev/sda7
/boot/efi: 0 B (dry run) trimmed on /dev/nvme0n1p1
/: 0 B (dry run) trimmed on /dev/nvme0n1p2
I am left with one last question. How do I prevent fstrim from touching my HDD. Also, since TRIM on HDD doesn’t make any sense, my hdd should be ignoring trim commands even if fstrim tries to trim hdd partition?
So I suppose it did something when I first ran it. HDD are not supposed to be trimmed afaik. The fstrim.timer tries to trim filesystems listed under /etc/fstab, meaning it will trim my hdd every week (since it thinks my hdd has trim support). Might be dangerous for my hdd?
Arch wiki says
Warning: Users need to be certain that their SSD supports TRIM before attempting to use it. Data loss can occur otherwise!
never see that trim was working on a spinning disk…
i mean:
DISC-GRAN discard granularity
DISC-MAX discard max bytes
This could not be there on a HDD aka spinning disk… i see sda5/6 are mounted on the filesystem of the ssd … but this should not be an issue…or could it?
sda6/7 are ext4 mounted on ssd. Is there some other way to access it without mounting on ssd?
Also, “disc-gran” and “disk-max” are supposed to be zero for HDD partitions, but its not so in my case. Maybe that is the reason why fstrim tries to trim sda6/7 also.
I researched some more and it looks like my HDD uses some technology which I wasn’t yet aware of.
So the HDD that’s there on my laptop uses Shingled Magnetic Recording. I am not geek enough to completely understand this thing, but what I understood is that it has denser data blocks. Writing data to a track requires the data on adjacent tracks to be re-written too, making the writes slower. A concern for people like me who write lot of data.
These types of HDD need trimming. And so lsblk and fstrim reported trim support on my HDD.
Western Digital, Toshiba and Seagate have sold SMR drives without labeling them as such, generating a large controversy, as SMR drives are much slower in some circumstances than PMR drives.[13] These practices were used in both data storage-dedicated (for servers, NASes and cold storage) and consumer-centric HDDs.
Edit: So I’ll enable the fstrim.timer and let it trim my hdd partition too, as it was doing earlier. Thanks everyone for your time.
Not perhaps relevant to the purpose here - but as a note the fstab entries you made for the extra drives should be terminated by 0 2 rather than 0 1 - as fsck can’t do them all first! Root / needs that option at 1 (and it usually added automatically) but other drives, if not to be skipped - should be marked as 2.
Sorry for wasting your time. 
