Some questions re a system with a NVME M.2 drive and a SSD drive only

[Blammar]

1. I should partition the 1TB Samsung 850 EVO drive (which appears as /dev/sda) as an ext4 file system if I want my weekly TRIM to work on it, right?

2. The M.2 drive, which the OS is installed on, is listed as /dev/nvme0n1 . "hdparm -I /dev/nvme0n1" returns stuff like "SG_IO: questionable sense data." However, "parted /dev/nvme0n1 -l" seems to work and does show the partitions and the ext4 file system. So can I assume that drive will be TRIM'd successfully?

3. I'm a bit confused about the mount command. Do I need to do it every time I boot my system? I took a look at the /etc/fstab file, and don't want to edit it by hand. Basically, I just want to mount /dev/sda as /home/foo/work or something similar.

4. And, as a completely different question, how can I map my caps lock key to ctrl so it works everywhere? I can make Konsole do the remapping, but that disappears when I close the window.

Thanks in advance!

[dibl]

I'll take a stab:

1. Yes. Not sure how you're planning to implement trim -- I wrote a little dissertation on SSD installations that might be useful.

2. I assume an nvme SSD works the same as MLC or eMLC -- googling about the provisioning capabilities of nvme might teach you more.

3. You will indeed need to manually make the mount points and edit /etc/fstab accordingly. Here's the mount line for one of my SSD partitions:

UUID=ec21f5b3-7fd4-4f4b-af8d-cf787b147ae8     /mnt/REVODATA        ext4         auto,users,rw,exec,noatime  0  0

4. I think KDE would let you do that, but I really question the wisdom of it. The Ctrl key has numerous built-in functions, such as Ctrl-Esc to view running processes and Ctrl-Alt-Fx to switch to the tty consoles. What are you going to do with those functions?

[jlittle]

4. And, as a completely different question, how can I map my caps lock key to ctrl so it works everywhere? I can make Konsole do the remapping, but that disappears when I close the window.

I'm not sure what you mean by "works everywhere":

1. If you mean throughout KDE, have you looked at System Settings, Input Devices (in the hardware section), Keyboard, Advanced tab, Caps Lock key behaviour?
2. If you mean in all desktop environments using X, you can use xmodmap. See the examples in man xmodmap, and note that Kubuntu sources a .Xmodmap in your home directory, via /etc/X11/Xsession.d/80kubuntu-xmodmap (on my 16.04, anyway). If you use xmodmap in one konsole, it will affect others, and persist after the konsole closes.

4. I think KDE would let you do that, but I really question the wisdom of it. The Ctrl key has numerous built-in functions...

Blammar wants to map Caps Lock to Ctrl, not necessarily vice versa. Millions of us think this is wise

[Blammar]

@jlittle: I edited /etc/default/keyboard, which appears to be the same file modified by the Systems Settings menu path you mentioned. Yes, this is making caps lock into a ctrl key. I've given up buying expensive keyboards where you can set that up in the hardware, and also swap the keycaps.

@dibl: right, I read some more and realized that. I had assumed that mount worked in the same way the equivalent Windows function did.

@dibl: I didn't plan to do anything other than the default invocation in /etc/cron.weekly/fstrim. What I was concerned about was whether or not the NVMe drive supported TRIM.

Looking at the code of /sbin/fstrim-all (kubuntu 14.04), it appears that if hdparm -I doesn't work on the device, fstrim won't be called. So there's definitely an issue here. Unfortunately, I'm locked into using 14.04 as the machine learning software I'm using only works in that (I did spend a day installing 15.10 and trying hard -- there were just too many dependencies on 14.04 for me to work around.)

-----------------

The SSD installation dissertation is excellent, thanks @dibl. That gets around the hdparm -I issue since the script there doesn't use hdparm. So I should be able to successfully trim all three of my SSD partitions now.

Final question: how do you remember to make all of these changes again when you upgrade the OS? I don't have that problem with Windows, but then, that OS gets more and more encrusted with crap over the years. I've never actually upgraded a window system's OS. I'm assuming that linux users upgrade fairly often.

------------------

Actually, the script fails on /boot/efi, where the DISC-MAX is greater than zero (because that is on the SSD), but because that's a boot filesystem, it's in fat32 format, which can't be TRIM'd. I hacked the script for now.

------------------

Oddly enough, there's no scheduler for the nvme drive (/sys/block/nvme0n1/queue/scheduler contains "none".) I edited the /etc/udev/rules.d ssd file, but the scheduler remained at "none". Given the measured performance matches the quoted performance of 2500 MB/sec read, I'm going to assume "none" is OK.

[dibl]

Final question: how do you remember to make all of these changes again when you upgrade the OS?

I don't. Running a rolling release OS, it's been 3 or 4 years since I last did an installation on an SSD, so there's no way my 65-year old brain would remember stuff like that. I have a folder full of "how-tos" where I look up how to resolve common problems and configuration items -- comes in very handy every once in awhile.

Oddly enough, there's no scheduler for the nvme drive (/sys/block/nvme0n1/queue/scheduler contains "none".) I edited the /etc/udev/rules.d ssd file, but the scheduler remained at "none". Given the measured performance matches the quoted performance of 2500 MB/sec read, I'm going to assume "none" is OK.

Interesting. Well, you are breaking new ground with your nvme SSD, so this information is good to know for everyone else.

[oshunluvr]

Not sure how the nvme differs from the standard interfaces, but I don't recommend mounting with the discard (trim) option in any case. It causes a reduction in performance and increases wear. Either run trim manually or if applicable as a monthly cronjob. Once a month or even every three months is often enough unless you're using the drive for constant data exchanges, like a web server or something.

[Blammar]

Not sure how the nvme differs from the standard interfaces, but I don't recommend mounting with the discard (trim) option in any case. It causes a reduction in performance and increases wear. Either run trim manually or if applicable as a monthly cronjob. Once a month or even every three months is often enough unless you're using the drive for constant data exchanges, like a web server or something.

Right, I made sure there's no discard option on the mount. I didn't realize a monthly cronjob would be good enough; it's currently set up to run weekly. Since doing a TRIM doesn't really consume SSD drive resources, as I understand, weekly or monthly shouldn't matter.

[oshunluvr]

Weekly would be recommended if your drive is nearer to full or you have a higher than normal file cycle rate (how often files are written to the drive). My personal opinion, monthly is fine for most users.