[gentoo-user] What are common SSDs does and don'ts.

[gentoo-user] What are common SSDs does and don'ts.

[Dale]

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

:-)  :-) 

Re: [gentoo-user] What are common SSDs does and don'ts.

[Mark Knecht]

On Sat, Mar 22, 2025 at 11:51 AM Dale <rdalek1967@gmail.com> 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?  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

Hi Dale,
   I suspect you're going to get as many responses as there are people
to respond. I personally treat them exactly like spinning rust. I've never
cared to try to adjust my computer life to do anything different. I've had
them in laptops and PCs for 8-10 years and none have ever failed.

   I'd rather do backups once a month to a rotating set of backup devices
vs being 'careful' which, in my life, has never really proved to solve
any of my computer problems.

   I hope whatever you do works for you.

   One website for these devices that I look at when purchasing is this:

https://ssd.userbenchmark.com

If you click on a drive you're interested in you get tested values from
other folks which is an interesting data point.

Cheers,
Mark

Re: [gentoo-user] What are common SSDs does and don'ts.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4097 bytes --]

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.

For more esoteric formatting on RAID arrays and assuming the necessary 
information is provided by the OEM, read here about block erase size:

https://wiki.gentoo.org/wiki/SSD

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.

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.


> 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. 

You can create udev rules to apply any options you need, but I don't know what 
options may be applied by default by udev.  Bear in mind, preferred mount 
options depend not only on the filesystem, but also on the USB controller and 
its ability to process SCSI commands (e.g. dumb UFDs Vs smart(er) UAS).


> 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? 

With older SSDs you may need to leave some spare capacity unused 
(overprovisioning).  Modern SSDs apply firmware based overprovisioning 
transparently to the user, and you are going to be filling them up 
relentlessly you should be able to increase the overprovisioning amount by 
using the OEM's utility software, or hdparm.

https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm

Personally, I just leave some non-partitioned space more as a force of habit 
than need.


> 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

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.


> 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 wouldn't go wrong by starting with these two pages:

https://wiki.gentoo.org/wiki/NVMe

https://wiki.gentoo.org/wiki/SSD

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

Michael wrote:
> 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

Added that to fstab for the NVME mount points. 

>
> Also, depending on your filesystem choice you could benefit from compression.
>
> For more esoteric formatting on RAID arrays and assuming the necessary 
> information is provided by the OEM, read here about block erase size:
>
> https://wiki.gentoo.org/wiki/SSD
>
> 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.
>
> 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.
>

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. 


>> 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. 
> You can create udev rules to apply any options you need, but I don't know what 
> options may be applied by default by udev.  Bear in mind, preferred mount 
> options depend not only on the filesystem, but also on the USB controller and 
> its ability to process SCSI commands (e.g. dumb UFDs Vs smart(er) UAS).
>

I'll see what the default mount options are next time I mount one. 
Given the amount of time that has passed, they may have the defaults set
to what is best already and may not require me to change anything.  Lots
of magic nowadays. 


>> 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? 
> With older SSDs you may need to leave some spare capacity unused 
> (overprovisioning).  Modern SSDs apply firmware based overprovisioning 
> transparently to the user, and you are going to be filling them up 
> relentlessly you should be able to increase the overprovisioning amount by 
> using the OEM's utility software, or hdparm.
>
> https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm
>
> Personally, I just leave some non-partitioned space more as a force of habit 
> than need.

Without knowing it would help, I kinda did that.  No idea that it would
prove helpful tho.  LOL 


>
>> 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
> 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.
>

With 128GBs of RAM, I don't have swap.  If I do set it up later for some
reason, I'll likely put it on a spinning rust drive somewhere.  It's not
like I don't have a few laying around.  :-)  Speaking of, see the prices
of used drives recently?  Holy crap.  O_O  I used to get a drive for
$160 or so and it is north of $200 now.  Bad thing is, they stay sold
out too. 


>> 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 wouldn't go wrong by starting with these two pages:
>
> https://wiki.gentoo.org/wiki/NVMe
>
> https://wiki.gentoo.org/wiki/SSD


Read those two.  May need to read them again, and set up the fstrim cron
job thing.  Good links tho. 

Dale

:-)  :-) 

Re: [gentoo-user] What are common SSDs does and don'ts.

[Matt Jolly]

Hi,

On 23/3/25 07:37, Michael wrote:
> 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 really don't have to worry about the number of writes to a modern
flash memory device. SD cards and particularly terrible early flash
storage devices may have hit write limits but regular use on a system
is quite unlikely to result in excessive writes to a device.

If you already _have_ the RAM feel free to use tmpfs, buying more
(relatively expensive) RAM to extend the lifetime of a far cheaper
component isn't really a good value proposition.

Here's the stats on one of my local NVMes for comparison:

Data Units Read                         : 148609192 (76.09 TB)
Data Units Written                      : 232034557 (118.80 TB)


It's a 1TB, consumer-level device, and there's probably still a good
decade of daily use left in it (including oddball projects like
compiling every package in ::gentoo) before I have to think about
replacing it due to age/usage; the bigger concern will be size and
bandwidth before the part actually ages out.

Cheers,

Matt

Re: [gentoo-user] What are common SSDs does and don'ts.

[netfab]

Le 22/03/25 à 21:37, Michael a tapoté :
> 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.

For firefox, you may want to disable cache-on-disk and enable
cache-on-memory instead of setting-up the tmpfs stuff.

https://netfab.frama.io/posts/disable-firefox-disk-cache/

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

netfab wrote:
> Le 22/03/25 à 21:37, Michael a tapoté :
>> 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.
> For firefox, you may want to disable cache-on-disk and enable
> cache-on-memory instead of setting-up the tmpfs stuff.
>
> 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. 

Dale

:-)  :-) 

Re: [gentoo-user] What are common SSDs does and don'ts.

[netfab]

Le 23/03/25 à 08:01, Dale a tapoté :
> netfab wrote:
> > Le 22/03/25 à 21:37, Michael a tapoté :
> >> 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.
> > For firefox, you may want to disable cache-on-disk and enable
> > cache-on-memory instead of setting-up the tmpfs stuff.
> >
> > 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. 

Yes. ~/.cache/mozilla/firefox/

Re: [gentoo-user] What are common SSDs does and don'ts.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Sunday, 23 March 2025 01:48:01 Greenwich Mean Time Dale wrote:
> Michael wrote:

> > 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.
[snip ...]

> 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. 

Even once every 3-6 months would be more than enough.  The SSDcronTRIM will 
check if your disk is filling up and will only run fstrim when/if it is 
needed.

https://chmatse.github.io/SSDcronTRIM/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

Michael wrote:
> On Sunday, 23 March 2025 01:48:01 Greenwich Mean Time Dale wrote:
>> Michael wrote:
>>> 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.
> [snip ...]
>
>> 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. 
> Even once every 3-6 months would be more than enough.  The SSDcronTRIM will 
> 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. 

I still haven't figured out how I want to setup the newest m.2 stick. 
I'm thinking about using dm-setup to encrypt it, or most of it anyway. 

Dale

:-)  :-) 

Re: [gentoo-user] What are common SSDs does and don'ts.

[Nate Eldredge]

> 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. 

fstrim is a filesystem-level operation, and needs support from the specific fs in the kernel (to know which blocks are unused and candidates for trimming, to lock them in some fashion so that they remain unused while the trimming is in progress, to keep checksums consistent, etc).  Some filesystems don't support it at all.  So there's no way it could operate on the level of an entire drive.

Re: [gentoo-user] What are common SSDs does and don'ts.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

Am Sun, Mar 23, 2025 at 04:41:58PM -0500 schrieb Dale:

> Michael wrote:
> > On Sunday, 23 March 2025 01:48:01 Greenwich Mean Time Dale wrote:
> >> Michael wrote:
> >>> 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.
> > [snip ...]
> >
> >> 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. 
> > Even once every 3-6 months would be more than enough.  The SSDcronTRIM will 
> > 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.  

For systemd, fstrim ships with a unit file to run it once a week. You could 
easily create something for cron. When my NAS is up again (my last remaining 
Gentoo system) I could look at how I did it.

> 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.

The size in the output is usually simply the entire free space. AFAIK fstrim 
does not remember what it trimmed at the previous run.

> 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. 

fstrim -a runs on all file systems. If there is unassigned (unpartitioned) 
space on your SSD, then that space is not written to anyways, thus there is 
no need for trimming that.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

“Today I watched my first porn movie.” – “And?” – “I was so young back then.”

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

Am Sat, Mar 22, 2025 at 09:37:37PM +0000 schrieb Michael:

> 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.

I’m experimenting with f2fs (the flash-friendly file system), but recently 
ran into a road block with it: it does not support shrinking. Ooops, so now 
I can’t enlarge / on my mini PC, because /home is f2fs.

> 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. 

This is for people who not only don’t want to have their data leaked, but 
also the information how much data is on their drive. As a private person 
that does not do any really dangerous business like politics, leaks and so 
on, this is an irrelevant attack vector for me.

> 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.

You can make --allow-discards a permanent option, if you combine it with 
--persistent. So you open the container with it once and then have to never think 
about it anymore.

> > Are there things I should do on occasion that will make them perform
> > better, last longer or both?

Steve Gibson, the author of SpinRite, had testimonials in his Security Now 
podcast of people using his tool on old SSDs that became very slow. 
Afterwards, the SSDs were back to their former glory. I guess because the 
tool read it from start to finish so the controller was forced to check 
every cell (that was in use).

> 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.

Ouh yeah, firefox writes a backup of its internal state every 15 s or so. 
If you leave many tabs open, this amounts to many 100 kB minute.
Check with iotop --only --accumulated


-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Save water! Dilute it!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]

Frank Steinmetzger wrote:
> Am Sun, Mar 23, 2025 at 04:41:58PM -0500 schrieb Dale:
>
>> Michael wrote:
>>> On Sunday, 23 March 2025 01:48:01 Greenwich Mean Time Dale wrote:
>>>> Michael wrote:
>>>>> 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.
>>> [snip ...]
>>>
>>>> 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. 
>>> Even once every 3-6 months would be more than enough.  The SSDcronTRIM will 
>>> 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.  
> For systemd, fstrim ships with a unit file to run it once a week. You could 
> easily create something for cron. When my NAS is up again (my last remaining 
> Gentoo system) I could look at how I did it.
>
>> 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.
> The size in the output is usually simply the entire free space. AFAIK fstrim 
> 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 made those big since I hope to be using that thing for a while and
nothing is on LVM or anything.  Adding more space could get
interesting.  I went big and still have almost 200GBs unused. 


>> 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. 
> fstrim -a runs on all file systems. If there is unassigned (unpartitioned) 
> space on your SSD, then that space is not written to anyways, thus there is 
> no need for trimming that.

I just created this.  I think this will work. 


root@Gentoo-1 / # cat /etc/cron.monthly/fstrim-nvme
#!/bin/sh

fstrim -v /
fstrim -v /var
root@Gentoo-1 / #


I'll try to remember when the next month comes up and see if it ran or
not.  It did when I ran run-parts thingy. 

I think once a month is plenty soon enough.  Weekly would just be to
much.  In another decade, we may not have to do anything to keep these
things going.  They just do their thing internally.  Heck, they have
improved a lot over the past decade. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 5498 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

Am Sun, Mar 23, 2025 at 06:24:49PM -0500 schrieb Dale:

> >> 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.
> > The size in the output is usually simply the entire free space. AFAIK fstrim 
> > 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

Funnily it does for me:

$ 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

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

A body has been found in the canal, tightly tied up in a sack.
Suicide seems out of the question.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

Frank Steinmetzger wrote:
> Am Sun, Mar 23, 2025 at 06:24:49PM -0500 schrieb Dale:
>
>>>> 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.
>>> The size in the output is usually simply the entire free space. AFAIK fstrim 
>>> 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
> Funnily it does for me:
>
> $ 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.  I'd be more likely to either wear out the stick and have to
replace it or this rig will become outdated and be replaced.  I even
made /boot large.  I could put Knoppix on there if I wanted. 

Speaking of, 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. 

Dale

:-)  :-) 

P. S.  I just ran the update command for your checksum script.  Another
torrent finished and I added a video file. 

Re: [gentoo-user] What are common SSDs does and don'ts.

[Peter Humphrey]

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.

-- 
Regards,
Peter.

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

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

:-)  :-) 

Re: [gentoo-user] What are common SSDs does and don'ts.

[Peter Humphrey]

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.

-- 
Regards,
Peter.

Re: [gentoo-user] What are common SSDs does and don'ts.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

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).

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[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. 

Dale

:-)  :-) 

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]

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. 

By the way, I copied some large files over to a m.2 external stick and
the copy was kinda slow.  I'm not sure what the cause of that is.  I've
never had much luck with speed over USB tho.  May be a missing kernel
option or something. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 4447 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Peter Humphrey]

On Tuesday, 1 April 2025 13:56:31 British Summer Time Dale wrote:
> 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. 

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.

-- 
Regards,
Peter.

Re: [gentoo-user] What are common SSDs does and don'ts.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4228 bytes --]

On Tuesday, 1 April 2025 14:03:06 British Summer Time Dale wrote:
> 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 / #

Yes, you would have all these and more for older amd, as well as intel CPUs, 
provided you have emerged sys-kernel/linux-firmware.


> I'm family 25 so not sure if those apply.

You'd need to read two wiki pages carefully.  The first explains how microcode 
can be built and included in your system, so that it is loaded as early as 
possible in the boot up process.  The idea is you'd want any CPU bugs to be 
patched before you use the CPU to load and start running your kernel.

https://wiki.gentoo.org/wiki/Microcode

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 firmware package puts it there.

I think the initrd builder (e.g. dracut) puts it there and GRUB loads it.


> 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 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

Am Tue, Apr 01, 2025 at 08:03:06AM -0500 schrieb 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.

Look at the readme in the same directory.
rour 25 (mine, too) is 0x19 in hex notation.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Electronically yours,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 3779 bytes --]

Am Mon, Mar 31, 2025 at 07:44:18PM -0500 schrieb Dale:

> > $ 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.

So am I.

/dev/mapper/vg-data: LABEL="data" TYPE="ext4"
/dev/mapper/vg-home: LABEL="home" TYPE="ext4"
/dev/mapper/vg-root: LABEL="arch" TYPE="ext4"
/dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="efi" LABEL="efi" TYPE="vfat"
/dev/nvme0n1p3: LABEL="windows" TYPE="ntfs"

(abbreviated for clarity)


> Could the file system make a difference if you use something else?  Your 
> root and /home is getting a little full.  o_O 

Root has always been kinda full. I tend to size it according to real-world 
need, so I have more usable space where it’s actually needed. This habit 
stems back to when I had a 120 GB hard drive in my laptop 20 years ago.

But LVM came in handy here; I’ve embiggened / at least twice by now.

Home doesn’t grow very fast, mostly “temp” photo downloads and Mail. I can 
actually look that up thanks to my borg snapshots and the file listings¹ I 
keep around for precicely such look-ups so I don’t have to actually attach 
the backup disk. ^^ From the first Borg snapshot onwards (dated June 2021), 
it’s been growing by about 5 ± 1 GB/year.

I’ve long been pondering merging the home and data partition, as there is an 
arbitrary separation of which photos I store where. That separation has an 
historical reason, too: back when I had my first SSD (120 GB), it was too 
small for anything but Winblows and / (then still Gentoo). Later, on a 
512 GB SSD, I added home and a large Windows games partition to it, but 
still had the 1 TB data partition on a hard drive. Home became too small for 
my photos, so I started a new hierarchy in /mnt/data, but without migration 
the existing digikam collection from /home. Big mistake.

Nowadays it’s 2 TB solid state in both laptop and PC. But merging the 
partition content would mean I need to reorganise my Borg backups, too.

> 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.

While / does grow over time as packages get bigger, I never saw a reason to 
keep it much larger than necessary, especially as storage space was tight 
back in the days due to budget problems.



¹ from my tree wrapper script.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.
Very funny Scotty... now beam down my pants!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

Peter Humphrey wrote:
> On Tuesday, 1 April 2025 13:56:31 British Summer Time Dale wrote:
>> 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. 
> 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. 


root@Gentoo-1 / # ls /boot/ | grep -E '.img|kernel'
-rw-r--r--  1 root root   148480 Mar 22 04:53 amd-uc.img
-rw-------  1 root root 15606048 Apr  1 16:34 initramfs-6.14.0-1.img
-rw-------  1 root root 12206262 Jul 23  2024 initramfs-6.9.10-1.img
-rw-------  1 root root 12418411 Jul 13  2024 initramfs-6.9.4-1.img
-rw-------  1 root root 12418472 Jul 13  2024 initramfs-6.9.4-2.img
-rw-------  1 root root 12419262 Jul 17  2024 initramfs-6.9.4-3.img
-rw-r--r--  1 root root 15897600 Apr  1 16:16 kernel-6.14.0-1
-rw-r--r--  1 root root 15385600 Aug 25  2024 kernel-6.9.10-1
-rw-r--r--  1 root root 14943232 Jul 13  2024 kernel-6.9.4-1
-rw-r--r--  1 root root 15021056 Jul 13  2024 kernel-6.9.4-2
-rw-r--r--  1 root root 15381504 Aug 25  2024 kernel-6.9.4-3
root@Gentoo-1 / #


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.  Given the
infrequent kernel updates, this image method is the most up to date
method.  If it updates, the new one loads on the next reboot, whenever
that happens. 

Thanks. 

Dale

:-)  :-) 

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 5204 bytes --]

Frank Steinmetzger wrote:
> Am Mon, Mar 31, 2025 at 07:44:18PM -0500 schrieb Dale:
>
>>> $ 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.
> So am I.
>
> /dev/mapper/vg-data: LABEL="data" TYPE="ext4"
> /dev/mapper/vg-home: LABEL="home" TYPE="ext4"
> /dev/mapper/vg-root: LABEL="arch" TYPE="ext4"
> /dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="efi" LABEL="efi" TYPE="vfat"
> /dev/nvme0n1p3: LABEL="windows" TYPE="ntfs"
>
> (abbreviated for clarity)
>
>
>> Could the file system make a difference if you use something else?  Your 
>> root and /home is getting a little full.  o_O 
> Root has always been kinda full. I tend to size it according to real-world 
> need, so I have more usable space where it’s actually needed. This habit 
> stems back to when I had a 120 GB hard drive in my laptop 20 years ago.
>
> But LVM came in handy here; I’ve embiggened / at least twice by now.
>
> Home doesn’t grow very fast, mostly “temp” photo downloads and Mail. I can 
> actually look that up thanks to my borg snapshots and the file listings¹ I 
> keep around for precicely such look-ups so I don’t have to actually attach 
> the backup disk. ^^ From the first Borg snapshot onwards (dated June 2021), 
> it’s been growing by about 5 ± 1 GB/year.
>
> I’ve long been pondering merging the home and data partition, as there is an 
> arbitrary separation of which photos I store where. That separation has an 
> historical reason, too: back when I had my first SSD (120 GB), it was too 
> small for anything but Winblows and / (then still Gentoo). Later, on a 
> 512 GB SSD, I added home and a large Windows games partition to it, but 
> still had the 1 TB data partition on a hard drive. Home became too small for 
> my photos, so I started a new hierarchy in /mnt/data, but without migration 
> the existing digikam collection from /home. Big mistake.
>
> Nowadays it’s 2 TB solid state in both laptop and PC. But merging the 
> partition content would mean I need to reorganise my Borg backups, too.

I still have some things under /mnt too.  After a big change a few years
ago, and a couple with me building the new rig, I did move some stuff to
places where it is more logical.  Given the amount of video data here, I
now organize even my pv's by the type of data.  Most is encrypted but
some is still plain file systems.  I want to buy enough hard drives that
even one of my data file system's is encrypted.  I didn't encrypt it in
the beginning and now it would take about 3 spare 16TB or 18TB drives
hard drives just to reorganize.  Create encrypted file system, move
files over and then have the old drives as spares.  I have not found a
way to encrypt in place without data loss. 

Sometimes old ways of doing things comes back to make problems. 
Usually, when I build a new rig, I fix that as I add to fstab. 
Sometimes tho, those old ways are hard to shake. 

>> 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.
> While / does grow over time as packages get bigger, I never saw a reason to 
> keep it much larger than necessary, especially as storage space was tight 
> back in the days due to budget problems.
>
>
>
> ¹ from my tree wrapper script.
>
> -- Grüße | Greetings | Salut | Qapla’ Please do not share anything
> from, with or about me on any social network. Very funny Scotty... now
> beam down my pants!


I still remember my first build and that little 30GB hard drive that was
for everything, OS and data.  Eventually, I added a separate drive for
/home.  Back then, 30GBs was a LOT of room.  That was about the biggest
drive they made back then, that was affordable anyway. 

This takes me back to around 2003 or so.  Computers have come a long
ways since then.  Hard drives have certainly grown.  Heck, they closer
to 30TBs than they are to 30GBs.  Have to watch my T's and G's there.  o_O 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 6731 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 5650 bytes --]

Michael wrote:
> On Tuesday, 1 April 2025 14:03:06 British Summer Time Dale wrote:
>> 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 / #
> Yes, you would have all these and more for older amd, as well as intel CPUs, 
> provided you have emerged sys-kernel/linux-firmware.
>

That I did ages ago, don't remember where that was mentioned tho. 


>> I'm family 25 so not sure if those apply.
> You'd need to read two wiki pages carefully.  The first explains how microcode 
> can be built and included in your system, so that it is loaded as early as 
> possible in the boot up process.  The idea is you'd want any CPU bugs to be 
> patched before you use the CPU to load and start running your kernel.
>
> https://wiki.gentoo.org/wiki/Microcode
>
> 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 firmware package puts it there.
> 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. 

Dale

:-)  :-) 

P. S.  I may start a new thread about my kernel upgrade process.  Just
to be sure that when I do it on those rare occasions that I am doing all
the right steps.  It has been working but I need to document this thing,
so I don't forget something.    ;-)

[-- Attachment #2: Type: text/html, Size: 9268 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 3978 bytes --]

On Wednesday, 2 April 2025 05:04:12 British Summer Time Dale wrote:
> Michael wrote:

> > 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 
firmware package puts it there.
> > 
> > I think the initrd builder (e.g. dracut) puts it there and GRUB loads it.
> 
> I was wondering where that came from.  Makes sense. 

Dracut is capable of building a separate initrd image with the required 
microcode for 'early microcode loading'.  This is picked up by GRUB and loaded 
first thing during boot.  This is the default dracut configuration since 
version 047.

It is explained here:

https://wiki.gentoo.org/wiki/Microcode#Dracut


> >> 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? 

Your system will boot regardless.  These are the permutations:

1. No microcode provided by you:

The MoBo will load and use whatever version of microcode has been embedded in 
the EFI firmware made available by the OEM.

2. Microcode provided - embedded within your main initrd:

The microcode will load as part of the main initrd.

3. Microcode provided - as a separate initrd image:

The separate microcode initrd image, e.g. amd-uc.img, will be picked up by 
GRUB and loaded early in the boot process.

4. Microcode provided - embedded in the kernel image itself:

The microcode binary blob is part of the kernel and will be loaded first 
before the rest of the kernel, provided the 'Firmware loading facility' 
[CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam19h.bin ...."] is built in 
the kernel and not configured as a module.

https://wiki.gentoo.org/wiki/
AMD_microcode#Supplying_the_microcode_files_to_the_kernel


> >> 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. 

Yes, good point.


> 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. 

Yes, you can have the microcode as a separate initrd image and GRUB will load 
it each time, irrespective of the kernel you boot with.

It is worth mentioning though, kernel code a few years old is not the safest 
way to run your machine, given the continuous improvements and security 
patches released by the kernel devs.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] What are common SSDs does and don'ts.

[Peter Humphrey]

On Wednesday, 2 April 2025 04:33:01 British Summer Time Dale wrote:

--->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?

I don't know your system well enough to predict what you can do, but I have 
that arrangement.

> 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

# ls -l /boot | grep -v rescue
total 78M
-rwxr-xr-x 1 root root 145K Apr  1 11:20 amd-uc.img
-rwxr-xr-x 1 root root 139K Apr  1 11:20 config-6.12.21-gentoo
-rwxr-xr-x 1 root root 136K Feb 21 10:43 config-6.6.74-gentoo
-rwxr-xr-x 1 root root 216K Dec 10 15:01 early_ucode.cpio
drwxr-xr-x 5 root root  16K May 28  2024 EFI
-rwxr-xr-x 1 root root  21M Apr  1 11:20 intel-uc.img
drwxr-xr-x 3 root root  16K Apr  1 11:22 loader
-rwxr-xr-x 1 root root 6.3M Apr  1 11:20 System.map-6.12.21-gentoo
-rwxr-xr-x 1 root root 5.9M Feb 21 10:43 System.map-6.6.74-gentoo
-rwxr-xr-x 1 root root  11M Apr  1 11:20 vmlinuz-6.12.21-gentoo
-rwxr-xr-x 1 root root  11M Feb 21 10:43 vmlinuz-6.6.74-gentoo

That's everything in /boot. Nothing about grub, because I don't use it, much 
preferring bootctl from systemd-utils (that's the only systemd package here), 
whence the loader/ directory. I keep a small rescue system on each machine, 
though these days it's usually used only for routine backups of the main 
system.

I don't know where the amd-uc.img comes from. It shouldn't exist in an Intel 
system, but if I delete it it just reappears. I'll track it down one day.

> 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.

Good point, if your kernels become that old.

-- 
Regards,
Peter.

Re: [gentoo-user] What are common SSDs does and don'ts.

[Dale]

Michael wrote:
> On Wednesday, 2 April 2025 05:04:12 British Summer Time Dale wrote:
>> Michael wrote:
>>> 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 
> firmware package puts it there.
>>> I think the initrd builder (e.g. dracut) puts it there and GRUB loads it.
>> I was wondering where that came from.  Makes sense. 
> Dracut is capable of building a separate initrd image with the required 
> microcode for 'early microcode loading'.  This is picked up by GRUB and loaded 
> first thing during boot.  This is the default dracut configuration since 
> version 047.
>
> It is explained here:
>
> https://wiki.gentoo.org/wiki/Microcode#Dracut
>
>
>>>> 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? 
> Your system will boot regardless.  These are the permutations:
>
> 1. No microcode provided by you:
>
> The MoBo will load and use whatever version of microcode has been embedded in 
> the EFI firmware made available by the OEM.
>
> 2. Microcode provided - embedded within your main initrd:
>
> The microcode will load as part of the main initrd.
>
> 3. Microcode provided - as a separate initrd image:
>
> The separate microcode initrd image, e.g. amd-uc.img, will be picked up by 
> GRUB and loaded early in the boot process.
>
> 4. Microcode provided - embedded in the kernel image itself:
>
> The microcode binary blob is part of the kernel and will be loaded first 
> before the rest of the kernel, provided the 'Firmware loading facility' 
> [CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam19h.bin ...."] is built in 
> the kernel and not configured as a module.
>
> https://wiki.gentoo.org/wiki/
> AMD_microcode#Supplying_the_microcode_files_to_the_kernel
>
>
>>>> 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. 
> Yes, good point.
>
>
>> 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. 
> Yes, you can have the microcode as a separate initrd image and GRUB will load 
> it each time, irrespective of the kernel you boot with.
>
> It is worth mentioning though, kernel code a few years old is not the safest 
> way to run your machine, given the continuous improvements and security 
> patches released by the kernel devs.
>


After some thought, I think I'm just going to stick with the dracut and
init thingy way.  I'd like to get rid of it but it does work.  In the
past, I had nightmares with init thingys, Mandriva days.  I've only ever
had one fail with dracut building it.  I'm kinda leaning towards file
corruption or something myself since it did work for a while. 

So, things stay as they are.  For the moment anyway. 

Dale

:-)  :-)