I am working a project where on my laptop I want to repartition my 1 TB NVMe SSD and utilize those new partitions to try out some noted “gaming” distros and see how they compare.
I have MX Linux as my daily driver and do not want to change that. But since the laptop has both integrated Intel Iris Xe Graphics and Nvidia RTX 3050 Ti, I use it extensively for my casual gaming needs. While there are a few hiccups with my gaming, they are nothing that limits my ability to play most of my games, older Windows games, notwithstanding.
But reading up on the distros out there that might be better suited for gaming, I want to test those out (not in a VM, obviously) on their own partitions on this laptop and see how they compare to MX Linux.
My first step was to make a Clonezilla image as backup and that was a very good thing.
Second step was to reduce the size of the current partition from using the full disk space to what I thought would be acceptable. I had a current usage of 114 GB and so figured surely 200 GB would be enough to ensure there would not be any data loss. (More on that later).
Third, I created 4 100 GB partitions to install each of the other distros. One of which I did not know at the time, later discovered, used the BTRFS system and would then not be discovered in my controlling GRUB on MX Linux.
I installed 3 that I wanted to test and scrapped the fourth once I saw the installer. Not only did Chimera OS not have a live option, but I had not seen such an archaic installer since perhaps my DOS days…LOL.
Of course, after each install, I rebooted into MX Linux and ran update-grub and it found each except Garuda, which I discovered was a BTRFS and I guess having never used such a distro, did not know that you would be required to install it standalone first and then any other distros. Which I assume would then mean using it’s own menu to boot to the others. Not sure I am interested in that, yet, but will deal with that later.
Now each time I installed a new distro on the next partition and rebooted to MX Linux, I did not notice any issues, until the last one. That is when I noticed that only one workspace existed (previously, I had 5) and it showed up only as “Workspace 1” even though the info on the workspace had retained my given label of “ItsFOSS & Browser.” This is where I do all of my research and testing out the ItsFOSS article recommendations. Okay, so no big deal on that issue. Could always recreate other workspaces.
But on the final reboot into MX Linux, opening terminal planted that window in the uppermost left of my screen and covered the panel that resides vertically left on the desktop. Not only could I not get “right click” to produce the normal menu to move, resize, etc. it seemed the system was frozen for a bit after loading the desktop. I would start to type a command and notice nothing was displayed. I tested my keyboard, display settings, even workspace settings which allow for a margin so that open windows never cover the left side panel. Nothing changed.
After a minute, I could type in terminal. But it was buggy. Each open window was lying atop every other window and there was no way to acces any of the hidden ones without using task manager to terminate each and every one, including task manager itself.
Well something was definitely wrong, so I figured I had experienced some data loss in shrinking the original partition from 950 GB down to 200 GB. So I restored my Clonezilla image and all was well again.
But recently I had opted on my home server (which only has the integrated AMD graphics) to test out some other distros and had installed them after partitioning it’s NVMe drive without any issues to my Debian Bookworm distro I use for it (of course very little is on that SSD as it is only used for server admin stuff). But when I did my first CLI update in PeppermintOS Devuan, I noticed something I had not seen on any of my other Linux distros: I was asked if I wanted to “Trim” the SSD.
I thought, I did not even know that was a thing in Linux! And of course the logic to me was that it maybe worked like defrag in Windows? It would ensure all that data on the drive was not written all over the place, keeping the disk space usage nice and tidy, no?
So once I encountered all these issues on the MX Linux drive, I thought maybe this time I should look at doing the TRIM on that drive first, then make an image for restorability, and try again to shrink MX partition and add the others.
My research revealed a lot of related commands I did not know and having never used the smartmontools before, I delved into how that could help me achieve my goals.
I ran
sudo fstrim -av
on the 1 TB NVMe disk with the following results:
- EFI is so small it happened instantly: 251.8 MB of a 300 MB partition
- Main partition trimmed 819.5 GB
Further research showed that Ubuntu (SystemD) has a service for this tool but checking my service manager in MX, there is no such service. Which is fine, I can add one, but also run it manually. However, most articles recommended doing that daily when you use it as much as I do.
And as I understand it better now:
Use of the TRIM command helps to optimize the capacity of an SSD by allowing garbage collection and background processes to ignore the invalid or obsolete data. The end result is faster data writes and reduced drive wear.
So I looked at the syslog and a few key lines seemed important, but I was unsure:
2024-07-04T06:26:38.809282-04:00 mx--acer smartd[2283]: Device: /dev/nvme0, number of Error Log entries increased from 142 to 164
2024-07-04T06:26:38.809311-04:00 mx--acer smartd[2283]: Sending warning via /usr/share/smartmontools/smartd-runner to root ...
Here is my smartctl data:
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 970 EVO Plus 1TB
Serial Number: S59ANM0W555364V
Firmware Version: 2B2QEXM7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 1,000,204,886,016 [1.00 TB]
Unallocated NVM Capacity: 0
Controller ID: 4
NVMe Version: 1.3
Number of Namespaces: 1
Namespace 1 Size/Capacity: 1,000,204,886,016 [1.00 TB]
Namespace 1 Utilization: 119,916,183,552 [119 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 553191cdcb
Local Time is: Thu Jul 4 07:00:50 2024 EDT
Firmware Updates (0x16): 3 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x03): S/H_per_NS Cmd_Eff_Lg
Maximum Data Transfer Size: 512 Pages
Warning Comp. Temp. Threshold: 85 Celsius
Critical Comp. Temp. Threshold: 85 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 7.80W - - 0 0 0 0 0 0
1 + 6.00W - - 1 1 1 1 0 0
2 + 3.40W - - 2 2 2 2 0 0
3 - 0.0700W - - 3 3 3 3 210 1200
4 - 0.0100W - - 4 4 4 4 2000 8000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 41 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 12,226,380 [6.25 TB]
Data Units Written: 9,312,151 [4.76 TB]
Host Read Commands: 77,233,903
Host Write Commands: 145,955,761
Controller Busy Time: 488
Power Cycles: 101
Power On Hours: 445
Unsafe Shutdowns: 90
Media and Data Integrity Errors: 0
Error Information Log Entries: 164
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 41 Celsius
Temperature Sensor 2: 33 Celsius
Error Information (NVMe Log 0x01, 16 of 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 164 0 0x5013 0x4004 - 0 0 -
Was not sure what in the above output was relevant, so I am giving all of it here.
My questions are:
If I TRIM the drive as I already have and then shrink the partition, will that ensure lack of data loss I experienced earlier? Should I maybe set the MX partition to 300 or 400 GB to ensure?
Another command I found, specifically related to NVMe SSDs, was:
The DEALLOCATE operation provides a similar capability in the nonvolatile memory express (NVMe) command set for Peripheral Component Interconnect Express SSDs.
So is one preferred over the other with respect to NVMe? Anyone familiar with the command and its benefits?
And of course all of the reading up on the maintenance of SSDs, especially for longevity, was relevant to the recent article @Rosika had discussed in “hdparm.” Which at the time of reading, I did not understand the importance of using such command on the SSD.
I would like to hear your thoughts on not only the shrinking/adding partitions steps, but the maintenance of NVMe SSDs as outlined above. I would also be interested in hearing why a Linux OS that uses BTRFS system cannot be combined in GRUB with all the ext4 distros. I am a “need-to-understand-why” person.
Hopefully, this will be useful not only to me and my projects, but to others as well.
Thanks,
Sheila