Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Dale
Frank Steinmetzger wrote:
> Am Tue, Apr 18, 2023 at 10:05:27AM -0500 schrieb Dale:
>
>> Given how I plan to use this drive, that should last a long time.  I'm
>> just putting the OS stuff on the drive and I compile on a spinning rust
>> drive and use -k to install the built packages on the live system.  That
>> should help minimize the writes.
> Well, 300 TB over 5 years is 60 TB per year, or 165 GB per day. Every day. 
> I’d say don’t worry. Besides: endurance tests showed that SSDs were able to 
> withstand multiples of their guaranteed TBW until they actually failed (of 
> course there are always exceptions to the rule).
>
>> I read about that bytes written.  With the way you explained it, it
>> confirms what I was thinking it meant.  That's a lot of data.  I
>> currently have around 100TBs of drives lurking about, either in my rig
>> or for backups.  I'd have to write three times that amount of data on
>> that little drive.  That's a LOT of data for a 500GB drive. 
> If you use ext4, run `dumpe2fs -h /dev/your-root-partition | grep Lifetime` 
> to see how much data has been written to that partition since you formatted 
> it. Just to get an idea of what you are looking at on your setup.
>


I skipped the grep part and looked at the whole output.  I don't recall
ever seeing that command before so I wanted to see what it did.  Dang,
lots of info. 

Filesystem created:   Sun Apr 15 03:24:56 2012
Lifetime writes:  993 GB

That's for the main / partition.  I have /usr on it's own partition tho. 

Filesystem created:   Sun Apr 15 03:25:48 2012
Lifetime writes:  1063 GB

I'd think that / and /usr would be the most changed parts of the OS. 
After all, /bin and /sbin are on / too as is /lib*.  If that is even
remotely correct, both would only be around 2TBs.  That dang thing may
outlive me even if I don't try to minimize writes.  ROFLMBO

Now that says a lot.  Really nice info. 

Thanks.

Dale

:-)  :-) 



Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Dale
Mark Knecht wrote:
>
>
> On Tue, Apr 18, 2023 at 2:15 PM Dale  > wrote:
> >
> > Mark Knecht wrote:
> >
> >
> >
> > On Tue, Apr 18, 2023 at 1:02 PM Dale  > wrote:
> > 
> > >
> > > Someone mentioned 16K block size.
> > 
> >
> > I mentioned it but I'm NOT suggesting it.
> >
> > It would be the -b option if you were to do it for ext4.
> >
> > I'm using the default block size (4k) on all my SSDs and M.2's and
> > as I've said a couple of time, I'm going to blast past the 5 year
> > warranty time long before I write too many terabytes.
> >
> > Keep it simple.
> >
> > - Mark
> >
> > One reason I ask, some info I found claimed it isn't even
> supported.  It actually spits out a error message and doesn't create
> the file system.  I wasn't sure if that info was outdated or what so I
> thought I'd ask.  I think I'll skip that part.  Just let it do its thing.
> >
> > Dale
> 
>
> I'd start with something like
>
> mkfs.ext4 -b 16384 /dev/sdX
>
> and see where it leads. It's *possible* that the SSD might fight 
> back, sending the OS a response that says it doesn't want to 
> do that.
>
> It could also be a partition alignment issue, although if you
> started your partition at the default starting address I'd doubt 
> that one.
>
> Anyway, I just wanted to be clear that I'm not worried about
> write amplification based on my system data.
>
> Cheers,
> Mark


I found where it was claimed it doesn't work.  This is the link.

https://askubuntu.com/questions/1007716/formatting-an-ext4-partition-with-a-16kb-block-possible

That is a few years old and things may have changed.  I also saw similar
info elsewhere.  I may try it just to see if I get the same output.  If
it works, fine.  If not, then we know.

Odd it would have the option but not allow you to use it tho.  :/

Dale

:-)  :-) 


Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Dale
Wols Lists wrote:
> On 18/04/2023 23:13, Frank Steinmetzger wrote:
>>> /var/tmp/portage on tmpfs. And on every disk I allocate a swap
>>> partition
>>> equal to twice the mobo's max memory. Three drives times 64GB times
>>> two is a
>>> helluva lot of swap.
>
>> Uhm … why? The moniker of swap = 2×RAM comes from times when RAM was
>> scarce.
>> What do you need so much swap for, especially with 32 GB RAM to begin
>> with?
>> And if you really do have use cases which cause regular swapping,
>> it’d be
>> less painful if you just added some more RAM.
>
> Actually, if you know your history, it does NOT come from "times when
> RAM was scarce". It comes from the original Unix swap algorithm which
> NEEDED twice ram.
>
> I've searched (unsuccessfully) on LWN for the story, but at some point
> (I think round about kernel 2.4.10) Linus ripped out all the ugly
> "optimisation" code, and anybody who ran the vanilla kernel with "swap
> but less than twice ram" found it crashed the instant the system
> touched swap. Linus was not sympathetic to people who hadn't read the
> release notes ...
>
> Andrea Arcangeli and someone else (I've forgotten who) wrote two
> competing memory managers in classic "Linus managerial style" as he
> played them off against each other.
>
> I've always allocated swap like that pretty much ever since. Maybe the
> new algorithm hasn't got the old wanting twice ram, maybe it has, I
> never found out, but I've not changed that habit.
>
> (NB This system is pretty recent, my previous system had iirc 8GB (and
> a maxed out value of 16GB), not enough for a lot of the bigger programs.
>
> Before that point, I gather it actually made a difference to the
> efficiency of the system as the optimisations kicked in, but everybody
> believed it was an old wives tale - until Linus did that ...
>
> Cheers,
> Wol
>
>


I've always had some swap but never twice the ram.  Even back on my
single core rig with 4GBs of ram, I only had a couple GBs or so of
swap.  Heck, I have swappiness set to 1 here on current rig.  I don't
want swap used unless it is to prevent a out of memory crash.  Given the
amount of memory available today, unless you know you still don't have
enough memory, swap really isn't needed.  Adding more memory is a much
better solution. 

I've actually considered disabling mine completely but sometimes Firefox
gets a wild hair and starts consuming memory.  When my TV stops playing,
I know it's at it again.  Hasn't happened in a while tho.  That's the
thing about swap, it usually slows a system to a crawl.  I can usually
tell if even a few MBs of swap is being used just by the slowness of the
system to respond to even simply changing from one desktop to another. 

The need for swap in most cases isn't what it used to be. 

Dale

:-)  :-) 



Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Wols Lists

On 18/04/2023 23:13, Frank Steinmetzger wrote:

/var/tmp/portage on tmpfs. And on every disk I allocate a swap partition
equal to twice the mobo's max memory. Three drives times 64GB times two is a
helluva lot of swap.



Uhm … why? The moniker of swap = 2×RAM comes from times when RAM was scarce.
What do you need so much swap for, especially with 32 GB RAM to begin with?
And if you really do have use cases which cause regular swapping, it’d be
less painful if you just added some more RAM.


Actually, if you know your history, it does NOT come from "times when 
RAM was scarce". It comes from the original Unix swap algorithm which 
NEEDED twice ram.


I've searched (unsuccessfully) on LWN for the story, but at some point 
(I think round about kernel 2.4.10) Linus ripped out all the ugly 
"optimisation" code, and anybody who ran the vanilla kernel with "swap 
but less than twice ram" found it crashed the instant the system touched 
swap. Linus was not sympathetic to people who hadn't read the release 
notes ...


Andrea Arcangeli and someone else (I've forgotten who) wrote two 
competing memory managers in classic "Linus managerial style" as he 
played them off against each other.


I've always allocated swap like that pretty much ever since. Maybe the 
new algorithm hasn't got the old wanting twice ram, maybe it has, I 
never found out, but I've not changed that habit.


(NB This system is pretty recent, my previous system had iirc 8GB (and a 
maxed out value of 16GB), not enough for a lot of the bigger programs.


Before that point, I gather it actually made a difference to the 
efficiency of the system as the optimisations kicked in, but everybody 
believed it was an old wives tale - until Linus did that ...


Cheers,
Wol



[gentoo-user] How to install Ruby bindings in an ebuild

2023-04-18 Thread Ralph Seichter
I need to install Ruby bindings (something.so) during an ebuild,
specifically into the /usr/lib64/ruby/vendor_ruby/3.0.0/x86_64-linux
directory. I scanned existing ebuilds for an example, but have not yet
found one. The developer manual [1] mentions newlib.so, but that
function appears to inject "/lib64" into the destination path on my
machine. Thus, I currently use the following crutch:

  exeinto /usr/lib64/ruby/vendor_ruby/3.0.0/x86_64-linux
  doexe ./bindings/ruby/something.so

While this works for the time being, this seems quite wrong to me,
because the destination path is obviously hardcoded. Is there perhaps
something in the ruby-utils or ruby-single eclasses I missed? I had
hoped to find support for installing vendor modules for Ruby here.

Your suggestiions are appreciated.

-Ralph

[1] https://devmanual.gentoo.org/function-reference/install-functions/index.html



Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Frank Steinmetzger
Am Wed, Apr 19, 2023 at 12:18:14AM +0200 schrieb Frank Steinmetzger:

> If you use ext4, run `dumpe2fs -h /dev/your-root-partition | grep Lifetime` 
> to see how much data has been written to that partition since you formatted 
> it. Just to get an idea of what you are looking at on your setup.

For comparison:

I’m writing from my Surface Go 1 right now. It’s running Arch linux with KDE 
and I don’t use it very often (meaning, I don’t update it as often as my 
main rig). But updates in Arch linux can be volume-intensive, especially 
because there are frequent kernel updates (I’ve had over 50 since June 2020, 
each accounting for over 300 MB of writes), and other updates of big 
packages if a dependency like python changes. In Gentoo you do revdep-rebuild,
binary distros ship new versions of all affected packages, like libreoffice, 
or Qt, or texlive.

Anyways, the root partition measures 22 G and has a lifetime write of 571 GB 
in almost three years. The home partition (97 GB in size) is at 877 GB. That 
seems actually a lot, because I don’t really do that much high-volume stuff 
there. My media archive with all the photos and music and such sits on a 
separate data partition, which is not synced to the Surface due to its small 
SSD of only 128 GB.

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

We shall be landing shortly.
Please return your stewardess to the upright position.


signature.asc
Description: PGP signature


Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Frank Steinmetzger
Am Tue, Apr 18, 2023 at 10:05:27AM -0500 schrieb Dale:

> Given how I plan to use this drive, that should last a long time.  I'm
> just putting the OS stuff on the drive and I compile on a spinning rust
> drive and use -k to install the built packages on the live system.  That
> should help minimize the writes.

Well, 300 TB over 5 years is 60 TB per year, or 165 GB per day. Every day. 
I’d say don’t worry. Besides: endurance tests showed that SSDs were able to 
withstand multiples of their guaranteed TBW until they actually failed (of 
course there are always exceptions to the rule).

> I read about that bytes written.  With the way you explained it, it
> confirms what I was thinking it meant.  That's a lot of data.  I
> currently have around 100TBs of drives lurking about, either in my rig
> or for backups.  I'd have to write three times that amount of data on
> that little drive.  That's a LOT of data for a 500GB drive. 

If you use ext4, run `dumpe2fs -h /dev/your-root-partition | grep Lifetime` 
to see how much data has been written to that partition since you formatted 
it. Just to get an idea of what you are looking at on your setup.

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

What woman is looking for a man who is looking for a woman looking for a man?


signature.asc
Description: PGP signature


Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Frank Steinmetzger
Am Tue, Apr 18, 2023 at 09:53:18PM +0100 schrieb Wol:

> On 18/04/2023 21:01, Dale wrote:
> > > I just use tmpfs for /var/tmp/portage (16GB, I'm on 32GB RAM.)

Same.

> /var/tmp/portage on tmpfs. And on every disk I allocate a swap partition
> equal to twice the mobo's max memory. Three drives times 64GB times two is a
> helluva lot of swap.

Uhm … why? The moniker of swap = 2×RAM comes from times when RAM was scarce. 
What do you need so much swap for, especially with 32 GB RAM to begin with?
And if you really do have use cases which cause regular swapping, it’d be 
less painful if you just added some more RAM.

I never used swap, even on my 3 GB laptop 15 years ago, except for extreme 
circumstances for which I specifically activated it (though I never compiled 
huge packages like Firefox or LO myself). These days I run a few zswap 
devices, which act as swap, but technically are compressed RAM disks. So 
when RAM gets full, I get a visible spike in the taskbar’s swap meter before 
the system grinds to a halt.

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

Night is so dark only so one can see it better.


signature.asc
Description: PGP signature


Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Mark Knecht
On Tue, Apr 18, 2023 at 2:15 PM Dale  wrote:
>
> Mark Knecht wrote:
>
>
>
> On Tue, Apr 18, 2023 at 1:02 PM Dale  wrote:
> 
> >
> > Someone mentioned 16K block size.
> 
>
> I mentioned it but I'm NOT suggesting it.
>
> It would be the -b option if you were to do it for ext4.
>
> I'm using the default block size (4k) on all my SSDs and M.2's and
> as I've said a couple of time, I'm going to blast past the 5 year
> warranty time long before I write too many terabytes.
>
> Keep it simple.
>
> - Mark
>
> One reason I ask, some info I found claimed it isn't even supported.  It
actually spits out a error message and doesn't create the file system.  I
wasn't sure if that info was outdated or what so I thought I'd ask.  I
think I'll skip that part.  Just let it do its thing.
>
> Dale


I'd start with something like

mkfs.ext4 -b 16384 /dev/sdX

and see where it leads. It's *possible* that the SSD might fight
back, sending the OS a response that says it doesn't want to
do that.

It could also be a partition alignment issue, although if you
started your partition at the default starting address I'd doubt
that one.

Anyway, I just wanted to be clear that I'm not worried about
write amplification based on my system data.

Cheers,
Mark


Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Dale
Mark Knecht wrote:
>
>
> On Tue, Apr 18, 2023 at 1:02 PM Dale  > wrote:
> 
> >
> > Someone mentioned 16K block size.
> 
>
> I mentioned it but I'm NOT suggesting it.
>
> It would be the -b option if you were to do it for ext4.
>
> I'm using the default block size (4k) on all my SSDs and M.2's and
> as I've said a couple of time, I'm going to blast past the 5 year
> warranty time long before I write too many terabytes.
>
> Keep it simple. 
>
> - Mark


One reason I ask, some info I found claimed it isn't even supported.  It
actually spits out a error message and doesn't create the file system. 
I wasn't sure if that info was outdated or what so I thought I'd ask.  I
think I'll skip that part.  Just let it do its thing. 

Dale

:-)  :-) 

P. S.  Kudos to however came up with Tylenol. 


Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Mark Knecht
On Tue, Apr 18, 2023 at 1:02 PM Dale  wrote:

>
> Someone mentioned 16K block size.


I mentioned it but I'm NOT suggesting it.

It would be the -b option if you were to do it for ext4.

I'm using the default block size (4k) on all my SSDs and M.2's and
as I've said a couple of time, I'm going to blast past the 5 year
warranty time long before I write too many terabytes.

Keep it simple.

- Mark


Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Wol

On 18/04/2023 21:01, Dale wrote:

I just use tmpfs for /var/tmp/portage (16GB, I'm on 32GB RAM.) When I
keep binary packages around, those I have on my HDD, as well as the
distfiles:

DISTDIR="/mnt/Data/gentoo/distfiles"
PKGDIR="/mnt/Data/gentoo/binpkgs"



Most of mine is in tmpfs to except for the larger packages, such as
Firefox, LOo and a couple others.  Thing is, those few large ones would
rack up a lot of writes themselves since they are so large.  That said,
it would be faster.  

Not sure if it's set up on my current system, but I always configured 
/var/tmp/portage on tmpfs. And on every disk I allocate a swap partition 
equal to twice the mobo's max memory. Three drives times 64GB times two 
is a helluva lot of swap.


So here I would just allocate /var/tmp/portage maybe 64 - 128 GB of 
space. If the emerge fits in my current 32GB ram, then fine. If not, it 
spills over into swap. I don't have to worry about allocating extra 
space for memory hogs like Firefox, LO, Rust etc.


And seeing as my smallest drive is 3TB, losing 128GB per drive to swap 
isn't actually that much.


Although, as was pointed out to me, if I did suffer a denial-of-service 
attack that tried to fill memory, that amount of swap would knacker my 
system for a LONG time.


Cheers,
Wol



Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Dale
Nikos Chantziaras wrote:
> On 18/04/2023 18:05, Dale wrote:
>> I compile on a spinning rust
>> drive and use -k to install the built packages on the live system.  That
>> should help minimize the writes.  
>
> I just use tmpfs for /var/tmp/portage (16GB, I'm on 32GB RAM.) When I
> keep binary packages around, those I have on my HDD, as well as the
> distfiles:
>
> DISTDIR="/mnt/Data/gentoo/distfiles"
> PKGDIR="/mnt/Data/gentoo/binpkgs"
>
>

Most of mine is in tmpfs to except for the larger packages, such as
Firefox, LOo and a couple others.  Thing is, those few large ones would
rack up a lot of writes themselves since they are so large.  That said,
it would be faster.  ;-) 


>> Since I still need a spinning rust
>> drive for swap and such, I thought about putting /var on spinning rust.
>
> Nah. The data written there is absolutely minuscule. Firefox writes
> like 10 times more just while running it without even any web page
> loaded... And for actual browsing, it becomes more like 1000 times
> more (mostly the Firefox cache.)
>
> I wouldn't worry too much about it. I've been using my current SSD
> since 2020, and I'm at 7TBW right now (out of 200 the drive is rated
> for) and I dual boot Windows and install/uninstall large games on it
> quite often. So with an average of 3TBW per year, I'd need over 80
> years to reach 200TBW :-P But I mentioned it in case your use case is
> different (like large video files or recording and whatnot.)
>
>
> .
>


That's kinda my thinking on one side of the coin.  Having it on a
spinning rust drive just wouldn't make much difference.  Most things
there like log files and such are just files being added to not
completely rewritten.  I don't think it would make much difference to
the life span of the drive. 

Someone mentioned 16K block size.  I've yet to find out how to do that. 
The man page talks about the option, -b I think, but google searches
seem to say it isn't supported.  Anyone actually set that option? 
Recall the options that were used? 

I did so much the past few days, I'm worthless today.  Parts of me are
pretty angry, joints and such.  Still, I'm glad I got done what I did. 
It's that busy time of year. 

Thanks.

Dale

:-)  :-) 



Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Mark Knecht
On Tue, Apr 18, 2023 at 7:53 AM Nikos Chantziaras  wrote:
>
> On 16/04/2023 01:47, Dale wrote:
> > Anything else that makes these special?  Any tips or tricks?
>
> Only three things.
>
> 1. Make sure the fstrim service is active (should run every week by
> default, at least with systemd, "systemctl enable fstrim.timer".)
>
> 2. Don't use the "discard" mount option.
>
> 3. Use smartctl to keep track of TBW.
>
> People are always mentioning performance, but it's not the important
> factor for me. The more important factor is longevity. You want your
> storage device to last as long as possible, and fstrim helps, discard
hurts.
>
> With "smartctl -x /dev/sda" (or whatever device your SSD is in /dev) pay
> attention to the "Data Units Written" field. Your 500GB 870 Evo has a
> TBW of 300TBW. That's "terabytes written". This is the manufacturer's
> "guarantee" that the device won't fail prior to writing that many
> terabytes to it. When you reach that, it doesn't mean it will fail, but
> it does mean you might want to start thinking of replacing it with a new
> one just in case, and then keep using it as a secondary drive.
>
> If you use KDE, you can also view that SMART data in the "SMART Status"
> UI (just type "SMART status" in the KDE application launcher.)
>

Add to that list that Samsung only warranties the drive for 5 years
no matter how much or how little you use it. Again, it doesn't mean
it will die in 5 years just as it doesn't mean it will die if it has had
more than 300TBW. However it _might_ mean that data written
to the drive and never touched again may be gone in 5 years.

Non-volatile memory doesn't hold it's charge forever, just as
magnetic disk drives and magnetic tape will eventually lose their
data.

On all of my systems here at home, looking at the TBW values, my
drives will go out of warranty at 5 years long before I'll get anywhere
near the TBW spec. However I run stable, long term distros that don't
update often and mostly use larger data files.


Re: [gentoo-user] Can I safely switch (no)multilib profile???

2023-04-18 Thread netfab
Le 18/04/23 à 17:25, Dr Rainer Woitok a tapoté :
> On Monday, 2023-04-17 13:49:57 +0200, you wrote:
> 
> > ...
> > Is the following file readable ?
> > 
> > > $ ls -l $(portageq get_repo_path / gentoo)/profiles/profiles.desc
> 
> Yes:
> 
>  [...]

Please post your emerge --info.





[gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Nikos Chantziaras

On 18/04/2023 18:05, Dale wrote:

I compile on a spinning rust
drive and use -k to install the built packages on the live system.  That
should help minimize the writes.  


I just use tmpfs for /var/tmp/portage (16GB, I'm on 32GB RAM.) When I 
keep binary packages around, those I have on my HDD, as well as the 
distfiles:


DISTDIR="/mnt/Data/gentoo/distfiles"
PKGDIR="/mnt/Data/gentoo/binpkgs"



Since I still need a spinning rust
drive for swap and such, I thought about putting /var on spinning rust.


Nah. The data written there is absolutely minuscule. Firefox writes like 
10 times more just while running it without even any web page loaded... 
And for actual browsing, it becomes more like 1000 times more (mostly 
the Firefox cache.)


I wouldn't worry too much about it. I've been using my current SSD since 
2020, and I'm at 7TBW right now (out of 200 the drive is rated for) and 
I dual boot Windows and install/uninstall large games on it quite often. 
So with an average of 3TBW per year, I'd need over 80 years to reach 
200TBW :-P But I mentioned it in case your use case is different (like 
large video files or recording and whatnot.)





Re: [gentoo-user] Can I safely switch (no)multilib profile???

2023-04-18 Thread Dr Rainer Woitok
Netfab,

On Monday, 2023-04-17 13:49:57 +0200, you wrote:

> ...
> Is the following file readable ?
> 
> > $ ls -l $(portageq get_repo_path / gentoo)/profiles/profiles.desc

Yes:

   $ ls -l $(portageq get_repo_path / gentoo)/profiles/profiles.desc
   -rw-r--r-- 1 root root 20443 2023-03-24 15:05 
/var/db/repos/gentoo/profiles/profiles.desc
   $ grep default/linux/amd64 $(portageq get_repo_path / 
gentoo)/profiles/profiles.desc
   amd64default/linux/amd64/17.1
stable
   amd64default/linux/amd64/17.1/selinux
stable
   amd64default/linux/amd64/17.1/hardened   
stable
   amd64default/linux/amd64/17.1/hardened/selinux   
stable
   amd64default/linux/amd64/17.1/desktop
stable
   amd64default/linux/amd64/17.1/desktop/gnome  
stable
   amd64default/linux/amd64/17.1/desktop/gnome/systemd  
stable
   amd64
default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr   stable
   amd64default/linux/amd64/17.1/desktop/plasma 
stable
   amd64default/linux/amd64/17.1/desktop/plasma/systemd 
stable
   amd64
default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr  stable
   amd64default/linux/amd64/17.1/desktop/systemd
stable
   amd64default/linux/amd64/17.1/desktop/systemd/merged-usr 
stable
   amd64default/linux/amd64/17.1/developer  
exp
   amd64default/linux/amd64/17.1/no-multilib
stable
   amd64default/linux/amd64/17.1/no-multilib/hardened   
stable
   amd64default/linux/amd64/17.1/no-multilib/hardened/selinux   
stable
   amd64default/linux/amd64/17.1/no-multilib/systemd
dev
   amd64default/linux/amd64/17.1/no-multilib/systemd/merged-usr 
dev
   amd64default/linux/amd64/17.1/no-multilib/systemd/selinux
exp
   amd64
default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr exp
   amd64default/linux/amd64/17.1/systemd
stable
   amd64default/linux/amd64/17.1/systemd/merged-usr 
stable
   amd64default/linux/amd64/17.1/systemd/selinux
exp
   amd64default/linux/amd64/17.1/systemd/selinux/merged-usr 
exp
   amd64default/linux/amd64/17.1/clang  
exp
   amd64default/linux/amd64/17.1/systemd/clang  
exp
   amd64default/linux/amd64/17.1/systemd/clang/merged-usr   
exp
   amd64default/linux/amd64/17.0/x32
dev
   amd64default/linux/amd64/17.0/x32/systemd
exp
   amd64default/linux/amd64/17.0/x32/systemd/merged-usr 
exp
   amd64default/linux/amd64/17.0/musl   
dev
   amd64default/linux/amd64/17.0/musl/clang 
exp
   amd64default/linux/amd64/17.0/musl/hardened  
exp
   amd64default/linux/amd64/17.0/musl/hardened/selinux  
exp
   amd64-linux  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ 
exp
   amd64-linux  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+  
exp
   amd64-linux  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+  
exp
   amd64-linux  default/linux/amd64/17.1/no-multilib/prefix/kernel-3.2+ 
exp
   amd64-linux  default/linux/amd64/17.1/no-multilib/prefix/kernel-2.6.32+  
exp
   amd64-linux  default/linux/amd64/17.1/no-multilib/prefix/kernel-2.6.16+  
exp
   $

Sincerely,
  Rainer



Re: [gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Dale
Nikos Chantziaras wrote:
> On 16/04/2023 01:47, Dale wrote:
>> Anything else that makes these special?  Any tips or tricks?
>
> Only three things.
>
> 1. Make sure the fstrim service is active (should run every week by
> default, at least with systemd, "systemctl enable fstrim.timer".)
>
> 2. Don't use the "discard" mount option.
>
> 3. Use smartctl to keep track of TBW.
>
> People are always mentioning performance, but it's not the important
> factor for me. The more important factor is longevity. You want your
> storage device to last as long as possible, and fstrim helps, discard
> hurts.
>
> With "smartctl -x /dev/sda" (or whatever device your SSD is in /dev)
> pay attention to the "Data Units Written" field. Your 500GB 870 Evo
> has a TBW of 300TBW. That's "terabytes written". This is the
> manufacturer's "guarantee" that the device won't fail prior to writing
> that many terabytes to it. When you reach that, it doesn't mean it
> will fail, but it does mean you might want to start thinking of
> replacing it with a new one just in case, and then keep using it as a
> secondary drive.
>
> If you use KDE, you can also view that SMART data in the "SMART
> Status" UI (just type "SMART status" in the KDE application launcher.)
>
>
>


I'm on openrc here but someone posted a link to make a cron job for
fstrim.  When I get around to doing something with the drive, it's on my
todo list.  I may go a month tho.  I only update my OS once a week, here
lately, every other week, and given the large amount of unused space, I
doubt it will run short of any space.  I'm still thinking on that. 

I've read about discard.  Gonna avoid that.  ;-) 

Given how I plan to use this drive, that should last a long time.  I'm
just putting the OS stuff on the drive and I compile on a spinning rust
drive and use -k to install the built packages on the live system.  That
should help minimize the writes.  Since I still need a spinning rust
drive for swap and such, I thought about putting /var on spinning rust. 
After all, when running software, activity on /var is minimal. Thing is,
I got a larger drive so I got plenty of space.  It could make it a
little faster.  Maybe. 

I read about that bytes written.  With the way you explained it, it
confirms what I was thinking it meant.  That's a lot of data.  I
currently have around 100TBs of drives lurking about, either in my rig
or for backups.  I'd have to write three times that amount of data on
that little drive.  That's a LOT of data for a 500GB drive. 

All good info and really helpful.  Thanks. 

Dale

:-)  :-) 



[gentoo-user] Re: Finally got a SSD drive to put my OS on

2023-04-18 Thread Nikos Chantziaras

On 16/04/2023 01:47, Dale wrote:

Anything else that makes these special?  Any tips or tricks?


Only three things.

1. Make sure the fstrim service is active (should run every week by 
default, at least with systemd, "systemctl enable fstrim.timer".)


2. Don't use the "discard" mount option.

3. Use smartctl to keep track of TBW.

People are always mentioning performance, but it's not the important 
factor for me. The more important factor is longevity. You want your 
storage device to last as long as possible, and fstrim helps, discard hurts.


With "smartctl -x /dev/sda" (or whatever device your SSD is in /dev) pay 
attention to the "Data Units Written" field. Your 500GB 870 Evo has a 
TBW of 300TBW. That's "terabytes written". This is the manufacturer's 
"guarantee" that the device won't fail prior to writing that many 
terabytes to it. When you reach that, it doesn't mean it will fail, but 
it does mean you might want to start thinking of replacing it with a new 
one just in case, and then keep using it as a secondary drive.


If you use KDE, you can also view that SMART data in the "SMART Status" 
UI (just type "SMART status" in the KDE application launcher.)





Re: [gentoo-user] Finally got a SSD drive to put my OS on

2023-04-18 Thread Frank Steinmetzger
Am Mon, Apr 17, 2023 at 10:45:46AM -0700 schrieb Mark Knecht:

> And I don't know that formatting ext4 or some other FS to 16K
> really helps the write amplification issue but it makes sense to
> me to match the file system blocks to the underlying flash
> block size.

The problem is finding out the write block size. This 7-year-old post says 
it’s reached 16 K: https://superuser.com/questions/976257/page-sizes-ssd

So I would say don’t bother. If everything is trimmed, there is no 
amplification. And if the disk becomes full and you get WA when writing 
itsy-bitsy 4 K files, you probably still won’t notice much difference, as 
random 4 K writes are slow anyways and how often do you write thousands of
4 K files outside of portage?

Erase block sizes probably go into the megabytes these days:
https://news.ycombinator.com/item?id=29165202

Some more detailed explanation:
https://spdk.io/doc/ssd_internals.html
  “For each erase block, each bit may be written to (i.e. have its bit 
  flipped from 0 to 1) with bit-granularity once. In order to write to the 
  erase block a second time, the entire block must be erased (i.e. all bits 
  in the block are flipped back to 0).”

This sounds like my initial statement was partially wrong – trimming does 
cause writing zeroes, because that’s what an erase does. But it still 
prevents write amplification (and one extra erase cycle) because 
neighbouring blocks don’t need to be read and written back.

> Real speed testing would be required to ensure reading
> 16K blocks doesn't slow him down though.

Here are some numbers and a conclusion gathered from a read test:
https://superuser.com/questions/728858/how-to-determine-ssds-nand-erase-block-size

Unless I positively need the speed for high-performance computing, I’d 
rather keep the smaller granularity for more capacity at low file sizes.

A problem is what some call “parts lottery” these days: manufacturers 
promise some performance on the data sheet (“up to xxx”), but not with which 
parts they want to achieve this (types of flash chips, TLC/QLC, controller, 
DRAM and so on). Meaning during the lifetime of a product, its internals may 
change and as a consequence those specs are not in the data sheet:

https://unix.stackexchange.com/questions/334804/is-there-a-way-to-find-out-ssd-page-size-on-linux-unix-what-is-physical-block
  “There is no standard way for a SSD to report its page size or erase block 
  size. Few if any manufacturers report them in the datasheets. (Because 
  they may change during the lifetime of a SKU, for example because of 
  changing suppliers.)
  For practical use just align all your data structures (partitions, payload 
  of LUKS containers, LVM logical volumes) to 1 or 2 MiB boundaries. It's an 
  SSD after all--it is designed to cope with usual filesystems, such as NTFS 
  (which uses 4 KiB allocation units).”

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

The worst disease is indifference. So what?


signature.asc
Description: PGP signature


Re: [gentoo-user] Can some config files be automatically protected from etc-update?

2023-04-18 Thread Neil Bothwick
On Tue, 18 Apr 2023 05:55:49 +0100, Wols Lists wrote:

> On 17/04/2023 19:26, Walter Dnes wrote:
> >Now that the (no)multilib problem in my latest update has been
> > solved, I have a somewhat minor complaint.  Can I get etc-update to
> > skip certain files?  My latest emerge world wanted to "update"...
> > 
> > 1) /etc/hosts (1)
> > 2) /etc/inittab (1)
> > 3) /etc/mtab (1)
> > 4) /etc/conf.d/consolefont (1)
> > 5) /etc/conf.d/hwclock (1)
> > 6) /etc/default/grub (1)
> > 7) /etc/ssh/sshd_config (1)
> > 
> > ...hosts is critical for networking.  consolefont allows me tp use the
> > true text console with a readable font, etc, etc.  I have my reasons
> > for making certain settings, and keeping them that way.
> >   
> I had it want to update grub. Which would have utterly borked my system 
> the moment I updated my kernel.
> 
> Okay, the problem is where you mix user and system config in the same 
> file, but this would have deleted lvm and mdadm from my boot config, 
> rendering any kernel unbootable. :-(
> 
> Like it tried to update postfix many moons ago and would have destroued 
> my mail config ...
> 
> Surely there's some way of fixing this ...

You could have a post-install hook in /etc/portage/env/$CAT/$PKG for each
of the affected files,  something like

post_pkg_postinst() {
  rm -f /etc/._cfg_hosts
}

You'll need to check the syntax as it's a while since I've used this.


-- 
Neil Bothwick

Life's a cache, and then you flush...


pgpAXMXm6uLuW.pgp
Description: OpenPGP digital signature