| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 56:31:16 |
| Calls: | 422 |
| Files: | 1,025 |
| Messages: | 90,789 |
Howdy,
As most know from other threads, I have a couple external m.2 NVME SSD
drives thingys. As of today, I now have a Crucial 480GB and 1TB and a Samsung 1TB drive. I also have a Samsung 1TB m.2 in my main rig for the
OS. I read some things ages ago about these things when they first came
out and people were still learning about what to do and not do with
them. At the time there was a lot of confusion as they were new and
people were testing options. I figure by now, it is fairly well known
what not to do with these things and what should be done to make them
perform well and last longer. So, I have questions but also feel free
to share other info as well that would be good to know. I plan to make
a cheat sheet out of the info.
First, for mount options. Should I have any mount options included in
fstab for the OS m.2 in my main rig?
Also, for the external USB mounted
ones, should I put mount options somewhere for those? If so, since
there is no fstab entries, where would I put those options? Some I use
the automount tool built into KDE.
Now to add more questions. I'm sure running shred, dd, wipe and other similar commands would shorten the life of one of these things. Is
there other things I should avoid doing that is common on spinning rust drives? Are there any other don'ts I should be aware of?
Are there things I should do on occasion that will make them perform
better, last longer or both? Keep in mind, some may only be mounted
with USB. That may limit some options. So far, the m.2 enclosure I use allows SMART to get info at least. Oh, what info does SMART give that I should keep a eye on for failures or problems? I also installed a
package that includes the nvme command. I'm not real sure what to do
with that thing, yet. o_o
Now that I have a few of these things, I don't want to do something that
lets the smoke out. O_O Oh, links to good info would also be OK.
Thanks.
Dale
:-) :-)
You probably want to alter the cache path for your browser from the SSD drive to your RAM (tmpfs), especially if you have a lot of RAM. Consider the same for any configurable applications which are caching heavily.
Also, if you use swap, then use zswap to reduce the amount written to the disk.
You probably want to alter the cache path for your browser from the
SSD drive to your RAM (tmpfs), especially if you have a lot of RAM.
netfab wrote:
Le 22/03/25 à 21:37, Michael a tapoté :
You probably want to alter the cache path for your browser from theFor firefox, you may want to disable cache-on-disk and enable cache-on-memory instead of setting-up the tmpfs stuff.
SSD drive to your RAM (tmpfs), especially if you have a lot of RAM.
https://netfab.frama.io/posts/disable-firefox-disk-cache/
Isn't the cache for Firefox inside the /home partition? If it is,
/home is on spinning rust still. Just the OS itself is on the m.2
stick.
Michael wrote:[snip ...]
Finally, consider TRIM being run on a cron job, or better use something like the SSDcronTRIM script once a month to decide and execute fstrim if needed.
The only thing on SSD is the OS itself. I have partitions for /efi,
/boot with ext2, / and /var with ext4. I'll set up fstrim later on.
Given I have a 1TB stick and left well over 100GBs unused, I should have
room left over to last a while. On my todo list tho. Would once a
month be often enough tho? I update each weekend. Other than that, not
much changes really. /home and such is on spinning rust still. If I
did daily updates, might be a better plan. Once a week, maybe monthly
will be OK.
On Mar 23, 2025, at 15:41, Dale <rdalek1967@gmail.com> wrote:
It looks like /var changes more than root does. I kinda wish I just
could run it on the whole m.2 stick and it do its thing regardless of
mount point. From the looks of the man page tho, that isn't a option.
Michael wrote:
On Sunday, 23 March 2025 01:48:01 Greenwich Mean Time Dale wrote:
Michael wrote:[snip ...]
Finally, consider TRIM being run on a cron job, or better use something >>> like the SSDcronTRIM script once a month to decide and execute fstrim if >>> needed.
The only thing on SSD is the OS itself. I have partitions for /efi,Even once every 3-6 months would be more than enough. The SSDcronTRIM will
/boot with ext2, / and /var with ext4. I'll set up fstrim later on.
Given I have a 1TB stick and left well over 100GBs unused, I should have >> room left over to last a while. On my todo list tho. Would once a
month be often enough tho? I update each weekend. Other than that, not >> much changes really. /home and such is on spinning rust still. If I
did daily updates, might be a better plan. Once a week, maybe monthly
will be OK.
check if your disk is filling up and will only run fstrim when/if it is needed.
https://chmatse.github.io/SSDcronTRIM/
That's not in the Gentoo tree. Hmmmmm.
I ran fstrim on my root and var partitions and got this.
root@Gentoo-1 / # fstrim -v /
/: 13.7 GiB (14676369408 bytes) trimmed
root@Gentoo-1 / # fstrim -v /var
/var: 43.9 GiB (47162359808 bytes) trimmed
root@Gentoo-1 / #
It looks like /var changes more than root does.
I kinda wish I just
could run it on the whole m.2 stick and it do its thing regardless of
mount point. From the looks of the man page tho, that isn't a option.
On Saturday, 22 March 2025 18:50:48 Greenwich Mean Time Dale wrote:
Howdy,
As most know from other threads, I have a couple external m.2 NVME SSD drives thingys. As of today, I now have a Crucial 480GB and 1TB and a Samsung 1TB drive. I also have a Samsung 1TB m.2 in my main rig for the OS. I read some things ages ago about these things when they first came out and people were still learning about what to do and not do with
them. At the time there was a lot of confusion as they were new and
people were testing options. I figure by now, it is fairly well known
what not to do with these things and what should be done to make them perform well and last longer. So, I have questions but also feel free
to share other info as well that would be good to know. I plan to make
a cheat sheet out of the info.
First, for mount options. Should I have any mount options included in fstab for the OS m.2 in my main rig?
Yes, noatime
Also, depending on your filesystem choice you could benefit from compression.
NOTE: With LUKS encrypted partitions you have to pay particular care - TRIM can compromise the security of your data and LUKS devs warn about it.
However, on a drive with a lot of re-write ops you will at some point need/ want to run fstrim. In this case you'll have to run cryptsetup with '--allow-
discards', before you run fstrim.
Are there things I should do on occasion that will make them perform better, last longer or both?
You probably want to alter the cache path for your browser from the SSD drive
to your RAM (tmpfs), especially if you have a lot of RAM.
I ran fstrim on my root and var partitions and got this.The size in the output is usually simply the entire free space. AFAIK fstrim
root@Gentoo-1 / # fstrim -v /
/: 13.7 GiB (14676369408 bytes) trimmed
root@Gentoo-1 / # fstrim -v /var
/var: 43.9 GiB (47162359808 bytes) trimmed
root@Gentoo-1 / #
It looks like /var changes more than root does.
does not remember what it trimmed at the previous run.
That doesn't match. They may have changed something.
%USED USED AVAILABLE TOTAL MOUNTED ON
11.3% 24.2G 348.5G 392.7G /
37.1% 47.3G 110.8G 176.1G /var
... I have /usr on the same partition as / this time around.
Do I need a init thingy still or can I ditch that thing? I do have /var
on a separate partition, if that matters.
Is there somewhere I can look or some command I can run to see if I load
any microcode that it needs to access while booting but before /var is mounted? Why isn't the microcode put in /usr or something anyway?
Peter Humphrey wrote:
On Tuesday, 1 April 2025 01:44:18 British Summer Time Dale wrote:
... I have /usr on the same partition as / this time around.
Do I need a init thingy still or can I ditch that thing? I do have /var >> on a separate partition, if that matters.
I have /var on a separate partition on some machines, and I only need an initrd for microcode loading. I suppose I could include that in the
kernel,
but I haven't tried that.
I thought about the fact I have a merged /usr now which means everything
is in /usr. I hadn't thought of microcode being needed tho. How do I
find out if there is any microcode being loaded on my system? I do have
the package installed, read somewhere that it only loads something if it
is needed so no real harm in having it installed even if nothing is
being used today. It could prove helpful if something is being used
later on tho.
Is there somewhere I can look or some command I can run to see if I load
any microcode that it needs to access while booting but before /var is mounted? Why isn't the microcode put in /usr or something anyway?
Dale
:-) :-)
Peter Humphrey wrote:
On Tuesday, 1 April 2025 11:12:44 British Summer Time Dale wrote:
Is there somewhere I can look or some command I can run to see if I load >> any microcode that it needs to access while booting but before /var is
mounted? Why isn't the microcode put in /usr or something anyway?
See https://wiki.gentoo.org/wiki/Microcode
That's the guide I followed.
I followed the link to the AMD one. Then I remembered that I do have microcode loading because I have a amd-uc.img file in /boot. I never
messed with it but when I update grub config, it finds that. I guess it
will need a init thingy since it has to have that to load the microcode
thing too. The devs have it so automatic, I forgot about the thing. It
only hit me when I read the wiki thing.
I guess I'll have to keep the init thingy. Now I know.
Michael wrote:
On Tuesday, 1 April 2025 11:12:44 British Summer Time Dale wrote:
Peter Humphrey wrote:
On Tuesday, 1 April 2025 01:44:18 British Summer Time Dale wrote:
... I have /usr on the same partition as / this time around.
Do I need a init thingy still or can I ditch that thing? I do have
/var
on a separate partition, if that matters.
I have /var on a separate partition on some machines, and I only need an >>> initrd for microcode loading. I suppose I could include that in the
kernel,
but I haven't tried that.
I thought about the fact I have a merged /usr now which means everything >> is in /usr. I hadn't thought of microcode being needed tho. How do I
find out if there is any microcode being loaded on my system? I do have >> the package installed, read somewhere that it only loads something if it >> is needed so no real harm in having it installed even if nothing is
being used today. It could prove helpful if something is being used
later on tho.
Is there somewhere I can look or some command I can run to see if I load >> any microcode that it needs to access while booting but before /var is
mounted? Why isn't the microcode put in /usr or something anyway?
Dale
:-) :-)
The microcode blobs are not in /usr, but in /lib/firmware; e.g.:
$ ls /lib/firmware/amd-ucode/
microcode_amd.bin microcode_amd_fam16h.bin
microcode_amd_fam19h.bin microcode_amd_fam15h.bin
microcode_amd_fam17h.bin README
You either include the microcode required by your CPU in an initrd, or build it in your kernel by specifying it - along with any firmware needed by your graphics, etc. - in your kernel (CONFIG_EXTRA_FIRMWARE).
I have these.
root@Gentoo-1 / # ls /lib/firmware/amd-ucode/
total 184
drwxr-xr-x 2 root root 4096 Dec 16 12:28 .
drwxr-xr-x 104 root root 20480 Mar 22 07:36 ..
-rw-r--r-- 1 root root 12684 Mar 22 04:52 microcode_amd.bin
-rw-r--r-- 1 root root 7876 Mar 22 04:52 microcode_amd_fam15h.bin -rw-r--r-- 1 root root 3510 Mar 22 04:52 microcode_amd_fam16h.bin -rw-r--r-- 1 root root 22596 Mar 22 04:52 microcode_amd_fam17h.bin -rw-r--r-- 1 root root 100684 Mar 22 04:52 microcode_amd_fam19h.bin -rw-r--r-- 1 root root 4662 Mar 22 04:52 README
root@Gentoo-1 / #
I'm family 25 so not sure if those apply.
Either way, I do have the
amd-uc.img thing in /boot. I think the firmware package puts it there.
Anyway, it finds it when I update grub config so I need a init thingy.
I was kinda hoping I could ditch it but I guess it is the best way to
load the microcode thing. I've read it is best to load the microcode
pretty early. It was a thought.
The microcode blobs are not in /usr, but in /lib/firmware; e.g.:
$ ls /lib/firmware/amd-ucode/
microcode_amd.bin microcode_amd_fam16h.bin microcode_amd_fam19h.bin
microcode_amd_fam15h.bin microcode_amd_fam17h.bin README
You either include the microcode required by your CPU in an initrd, or build
it in your kernel by specifying it - along with any firmware needed by your
graphics, etc. - in your kernel (CONFIG_EXTRA_FIRMWARE).
I have these.
root@Gentoo-1 / # ls /lib/firmware/amd-ucode/
total 184
drwxr-xr-x 2 root root 4096 Dec 16 12:28 .
drwxr-xr-x 104 root root 20480 Mar 22 07:36 ..
-rw-r--r-- 1 root root 12684 Mar 22 04:52 microcode_amd.bin -rw-r--r-- 1 root root 7876 Mar 22 04:52 microcode_amd_fam15h.bin -rw-r--r-- 1 root root 3510 Mar 22 04:52 microcode_amd_fam16h.bin -rw-r--r-- 1 root root 22596 Mar 22 04:52 microcode_amd_fam17h.bin -rw-r--r-- 1 root root 100684 Mar 22 04:52 microcode_amd_fam19h.bin -rw-r--r-- 1 root root 4662 Mar 22 04:52 README
root@Gentoo-1 / #
I'm family 25 so not sure if those apply.
$ journalctl -fu fstrim
Mär 31 23:03:26 q systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Mär 31 23:06:27 q fstrim[4946]: /mnt/windows: 62.6 GiB (67195392000 bytes) trimmed on /dev/nvme0n1p3
Mär 31 23:06:27 q fstrim[4946]: /mnt/gentoo: 25.1 GiB (26987544576 bytes) trimmed on /dev/vg/gentoo
Mär 31 23:06:27 q fstrim[4946]: /mnt/data: 410.3 GiB (440560844800 bytes) trimmed on /dev/vg/data
Mär 31 23:06:27 q fstrim[4946]: /home: 14.5 GiB (15569068032 bytes) trimmed on /dev/vg/home
Mär 31 23:06:27 q fstrim[4946]: /boot: 211.4 MiB (221700096 bytes) trimmed on /dev/nvme0n1p1
Mär 31 23:06:27 q fstrim[4946]: /: 8.6 GiB (9203961856 bytes) trimmed on /dev/vg/root
Mär 31 23:06:27 q systemd[1]: fstrim.service: Deactivated successfully.
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg-data 1.4T 956G 411G 70% /mnt/data /dev/mapper/vg-gentoo 50G 25G 25G 50% /mnt/gentoo /dev/mapper/vg-home 199G 184G 15G 93% /home
/dev/mapper/vg-root 50G 41G 8.2G 84% /
/dev/nvme0n1p1 300M 89M 212M 30% /boot
/dev/nvme0n1p3 196G 133G 63G 68% /mnt/windows
I'm using ext4 for my file system.
Could the file system make a difference if you use something else? Your root and /home is getting a little full. o_O
I didn't put anything OS related on LVM this time. With a 1TB stick, I figured I could make everything big enough that I shouldn't ever run out
of space.
8
I guess I'll have to keep the init thingy. Now I know.
I don't see why, Dale. I don't use one and my case is similar to yours. When I said I used one for microcode loading, I meant that the microcode image /is/ the initrd.
Ahhhh. I have both. I have the microcode image as well as a init
image. Are you saying I can have just the microcode image and no
initramfs image and it will still boot?
If you don't mind, can you list what is in your /boot, just the kernel and init stuff that grub uses to boot is enough. As a example, this is mine, with the command I used. You may name things differently tho so adjust if needed.
8
It uses the same microcode image for them all but as you can see, I have
5 boot options. I just created a new kernel and friends but have not rebooted yet. I'll clean those up and get down to two or three one of
these days. If I didn't have the init thingy at all for one or more of those, it would still boot with just a microcode image and kernel?
I read a link on this and I may point the kernel to the directory for it
to be included into the kernel. The only downside of that, old kernels
will have old microcode whereas this way, that microcode image gets
updated and on each reboot, loads the new microcode.
Michael wrote:firmware package puts it there.
The second page, relevant to AMD CPUs, points to the particular microcode blob you'd need to use for your CPU:
https://wiki.gentoo.org/wiki/AMD_microcode
It explains the hexadecimal number '19h' corresponds to your decimal '25'. Therefore your family 25 CPU requires the 'amd-ucode/microcode_amd_fam19h' blob. Whether you build this as part of your initrd, or you specify it in your kernel config so it becomes part of the kernel image, is your call.
Either way, I do have the amd-uc.img thing in /boot. I think the
I think the initrd builder (e.g. dracut) puts it there and GRUB loads it.
I was wondering where that came from. Makes sense.
Anyway, it finds it when I update grub config so I need a init thingy.
You do not need an initrd if the only reason for running an initrd image
is to load your microcode. The kernel is perfectly capable of doing this on its own - see the above links.
I was just clarifying that with Peter. So, if I have a microcode image
and a kernel, it will boot, with no init thingy?
I was kinda hoping I could ditch it but I guess it is the best way to
load the microcode thing. I've read it is best to load the microcode
pretty early. It was a thought.
It's a good thought and your hope can still be realised. I suggest you start with reading the above two links.
I been reading those, a couple times or so. Just trying to clear up the
mud. LOL While I would like to just include this in the kernel itself,
that may not be the best for my situation. I may update the kernel once
a year, if that. If I have a kernel as a backup that is three or four
years old, it will have microcode that is that old as well and lack any
new updates. Having it as a image means it will be updated when needed
and have the new code whenever I reboot. So, for my situation, having
older kernels as backups and such, it may be better to have the image
method instead of including it into the kernel.
I'm still thinking on this but if I understand this correctly, having a microcode image and kernel is the best way for me if I can remove the
init thingy from the process. It sounds like I can.