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

[Wol]

On 20/04/2023 05:23, Dale wrote:

Some 1,100 directories, not sure if directories use inodes or not.


"Everything is a file".

A directory is just a data file with a certain structure that maps names 
to inodes.


It might still be there somewhere - I can't imagine it's been deleted, 
just forgotten - but I believe some editors (emacs probably) would let 
you open that file, so you could rename files by editing the line that 
defined them, you could unlink a file by deleting the line, etc etc.


Obviously a very dangerous mode, but Unix was always happy about handing 
out powerful footguns willy nilly.


Cheers,
Wol

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

[Frank Steinmetzger]

Am Thu, Apr 20, 2023 at 04:29:59AM -0500 schrieb Dale:

> >> I wonder.  Is there a way to find out the smallest size file in a
> >> directory or sub directory, largest files, then maybe a average file
> >> size???
> > The 20 smallest:
> > `find -type f -print0 | xargs -0 stat -c '%s %n' | sort -n | head -n 20`
> >
> > The 20 largest: either use tail instead of head or reverse sorting with -r.
> > You can also first pipe the output of stat into a file so you can sort and 
> > analyse the list more efficiently, including calculating averages.
> 
> When I first run this while in / itself, it occurred to me that it
> doesn't specify what directory.  I thought maybe changing to the
> directory I want it to look at would work but get this: 

Yeah, either cd into the directory first, or pass it to find. But it’s like 
tar: I can never remember in which order I need to feed stuff to find. One 
relevant addition could be -xdev, to have find halt at file system 
boundaries. So:

find /path/to/dir -xdev -type f -! -type l …

> root@fireball /home/dale/Desktop/Crypt # `find -type f -print0 | xargs
> -0 stat -c '%s %n' | sort -n | head -n 20`
> -bash: 2: command not found
> root@fireball /home/dale/Desktop/Crypt #

I used the `` in the mail text as a kind of hint: “everything between is a 
command”. So when you paste that into the terminal, it is executed, and the 
result of it is substituted. Meaning: the command’s output is taken as the 
new input and executed. And since the first word of the output was “2”, you 
get that error message. Sorry about the confusion.

> >> I thought about du but given the number of files I have here,
> >> it would be a really HUGE list of files.  Could take hours or more too. 
> > I use a “cache” of text files with file listings of all my external drives. 
> > This allows me to glance over my entire data storage without having to plug 
> > in any drive. It uses tree underneath to get the list:
> >
> > `tree -afx -DFins --dirsfirst --du --timefmt "%Y-%m-%d %T"`
> >
> > This gives me a list of all directories and files, with their full path, 
> > date and size information and accumulated directory size in a concise 
> > format. Add -pug to also include permissions.
> >
> 
> Save this for later use.  ;-)

I built a wrapper script around it, to which I pass the directory I want to 
read (usually the root of a removable media). The script creates a new text 
file, with the current date and the dircetory in its name, and compresses it 
at the end. This allows me to diff those files in vim and see what changed 
over time. It also updates a symlink to the current version for quick access 
via bash alias.

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

...llaw eht no rorrim ,rorriM


signature.asc
Description: PGP signature

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

[Dale]

Peter Humphrey wrote:
> On Thursday, 20 April 2023 10:29:59 BST Dale wrote:
>> Frank Steinmetzger wrote:
>>> Am Wed, Apr 19, 2023 at 06:32:45PM -0500 schrieb Dale:
 Frank Steinmetzger wrote:
> <<>>
>
> When formatting file systems, I usually lower the number of inodes from
> the
> default value to gain storage space. The default is one inode per 16 kB
> of
> FS size, which gives you 60 million inodes per TB. In practice, even one
> million per TB would be overkill in a use case like Dale’s media
> storage.¹
> Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB,
> not counting extra control metadata and ext4 redundancies.
 If I ever rearrange my
 drives again and can change the file system, I may reduce the inodes at
 least on the ones I only have large files on.  Still tho, given I use
 LVM and all, maybe that isn't a great idea.  As I add drives with LVM, I
 assume it increases the inodes as well.
>>> I remember from yesterday that the manpage says that inodes are added
>>> according to the bytes-per-inode value.
>>>
 I wonder.  Is there a way to find out the smallest size file in a
 directory or sub directory, largest files, then maybe a average file
 size???
>>> The 20 smallest:
>>> `find -type f -print0 | xargs -0 stat -c '%s %n' | sort -n | head -n 20`
>>>
>>> The 20 largest: either use tail instead of head or reverse sorting with
>>> -r.
>>> You can also first pipe the output of stat into a file so you can sort and
>>> analyse the list more efficiently, including calculating averages.
>> When I first run this while in / itself, it occurred to me that it
>> doesn't specify what directory.  I thought maybe changing to the
>> directory I want it to look at would work but get this: 
>>
>>
>> root@fireball /home/dale/Desktop/Crypt # `find -type f -print0 | xargs
>> -0 stat -c '%s %n' | sort -n | head -n 20`
>> -bash: 2: command not found
>> root@fireball /home/dale/Desktop/Crypt #
>>
>>
>> It works if I'm in the / directory but not when I'm cd'd to the
>> directory I want to know about.  I don't see a spot to change it.  Ideas.
> In place of "find -type..." say "find / -type..."
>


Ahhh, that worked.  I also realized I need to leave off the ' at the
beginning and end.  I thought I left those out.  I copy and paste a
lot.  lol 

It only took a couple dozen files to start getting up to some size. 
Most of the few small files are text files with little notes about a
video.  For example, if building something I will create a text file
that lists what is needed to build what is in the video.  Other than a
few of those, file size reaches a few 100MBs pretty quick.  So, the
number of small files is pretty small.  That is good to know. 

Thanks for the command.  I never was good with xargs, sed and such.  It
took me a while to get used to grep.  ROFL 

Dale

:-)  :-) 

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

[Peter Humphrey]

On Thursday, 20 April 2023 10:29:59 BST Dale wrote:
> Frank Steinmetzger wrote:
> > Am Wed, Apr 19, 2023 at 06:32:45PM -0500 schrieb Dale:
> >> Frank Steinmetzger wrote:
> >>> <<>>
> >>> 
> >>> When formatting file systems, I usually lower the number of inodes from
> >>> the
> >>> default value to gain storage space. The default is one inode per 16 kB
> >>> of
> >>> FS size, which gives you 60 million inodes per TB. In practice, even one
> >>> million per TB would be overkill in a use case like Dale’s media
> >>> storage.¹
> >>> Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB,
> >>> not counting extra control metadata and ext4 redundancies.
> >> 
> >> If I ever rearrange my
> >> drives again and can change the file system, I may reduce the inodes at
> >> least on the ones I only have large files on.  Still tho, given I use
> >> LVM and all, maybe that isn't a great idea.  As I add drives with LVM, I
> >> assume it increases the inodes as well.
> > 
> > I remember from yesterday that the manpage says that inodes are added
> > according to the bytes-per-inode value.
> > 
> >> I wonder.  Is there a way to find out the smallest size file in a
> >> directory or sub directory, largest files, then maybe a average file
> >> size???
> > 
> > The 20 smallest:
> > `find -type f -print0 | xargs -0 stat -c '%s %n' | sort -n | head -n 20`
> > 
> > The 20 largest: either use tail instead of head or reverse sorting with
> > -r.
> > You can also first pipe the output of stat into a file so you can sort and
> > analyse the list more efficiently, including calculating averages.
> 
> When I first run this while in / itself, it occurred to me that it
> doesn't specify what directory.  I thought maybe changing to the
> directory I want it to look at would work but get this: 
> 
> 
> root@fireball /home/dale/Desktop/Crypt # `find -type f -print0 | xargs
> -0 stat -c '%s %n' | sort -n | head -n 20`
> -bash: 2: command not found
> root@fireball /home/dale/Desktop/Crypt #
> 
> 
> It works if I'm in the / directory but not when I'm cd'd to the
> directory I want to know about.  I don't see a spot to change it.  Ideas.

In place of "find -type..." say "find / -type..."

-- 
Regards,
Peter.

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

[Dale]

Peter Humphrey wrote:
> On Wednesday, 19 April 2023 18:59:26 BST Dale wrote:
>> Peter Humphrey wrote:
>>> On Wednesday, 19 April 2023 09:00:33 BST Nikos Chantziaras wrote:
 With my HDD:
# smartctl -x /dev/sda | grep -i 'sector size'
Sector Sizes: 512 bytes logical, 4096 bytes physical
>>> Or, with an NVMe drive:
>>>
>>> # smartctl -x /dev/nvme1n1 | grep -A2 'Supported LBA Sizes'
>>> Supported LBA Sizes (NSID 0x1)
>>> Id Fmt  Data  Metadt  Rel_Perf
>>>
>>>  0 + 512   0 0
>>>  
>>> :)
>> When I run that command, sdd is my SDD drive, ironic I know.  Anyway, it
>> doesn't show block sizes.  It returns nothing.
> I did say it was for an NVMe drive, Dale. If your drive was one of those, the 
> kernel would have named it /dev/nvme0n1 or similar.
>

Well, I was hoping it would work on all SDD type drives.  ;-) 

Dale

:-)  :-)

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

[Dale]

eric wrote:
> On 4/19/23 21:23, Dale wrote:
>> Mark Knecht wrote:
>>>
>>> > I wonder.  Is there a way to find out the smallest size file in a
>>> directory or sub directory, largest files, then maybe a average file
>>> size???  I thought about du but given the number of files I have
>>> here, it would be a really HUGE list of files. Could take hours or
>>> more too.  This is what KDE properties shows.
>>>
>>> I'm sure there are more accurate ways but
>>>
>>> sudo ls -R / | wc
>>>
>>> give you the number of lines returned from the ls command. It's not
>>> perfect as there are blank lines in the ls but it's a start.
>>>
>>> My desktop machine has about 2.2M files.
>>>
>>> Again, there are going to be folks who can tell you how to remove
>>> blank lines and other cruft but it's a start.
>>>
>>> Only takes a minute to run on my Ryzen 9 5950X. YMMV.
>>>
>>
>> I did a right click on the directory in Dolphin and selected
>> properties.  It told me there is a little over 55,000 files.  Some
>> 1,100 directories, not sure if directories use inodes or not.
>> Basically, there is a little over 56,000 somethings on that file
>> system.  I was curious what the smallest file is and the largest. No
>> idea how to find that really.  Even du separates by directory not
>> individual files regardless of directory.  At least the way I use it
>> anyway.
>>
>> If I ever have to move things around again, I'll likely start a
>> thread just for figuring out the setting for inodes.  I'll likely
>> know more about the number of files too.
>>
>> Dale
>>
>> :-)  :-)
>
> If you do not mind using graphical solutions, Filelight can help you
> easily visualize where your largest directories and files are residing.
>
> https://packages.gentoo.org/packages/kde-apps/filelight
>
>> Visualise disk usage with interactive map of concentric, segmented rings 
>
> Eric
>
> .
>

There used to be a KDE app that worked a bit like this.  I liked it but
I think it died.  I haven't seen it in ages, not long after the switch
from KDE3 to KDE4 I think.  Given the volume of files and the size of
the data, I wish I could zoom in sometimes.  Those little ones disappear. 

Thanks for that info. Nifty. 

Dale

:-)  :-) 

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

[Peter Humphrey]

On Wednesday, 19 April 2023 18:59:26 BST Dale wrote:
> Peter Humphrey wrote:
> > On Wednesday, 19 April 2023 09:00:33 BST Nikos Chantziaras wrote:
> >> With my HDD:
> >># smartctl -x /dev/sda | grep -i 'sector size'
> >>Sector Sizes: 512 bytes logical, 4096 bytes physical
> > 
> > Or, with an NVMe drive:
> > 
> > # smartctl -x /dev/nvme1n1 | grep -A2 'Supported LBA Sizes'
> > Supported LBA Sizes (NSID 0x1)
> > Id Fmt  Data  Metadt  Rel_Perf
> > 
> >  0 + 512   0 0
> >  
> > :)
> 
> When I run that command, sdd is my SDD drive, ironic I know.  Anyway, it
> doesn't show block sizes.  It returns nothing.

I did say it was for an NVMe drive, Dale. If your drive was one of those, the 
kernel would have named it /dev/nvme0n1 or similar.

-- 
Regards,
Peter.

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

[Dale]

Frank Steinmetzger wrote:
> Am Wed, Apr 19, 2023 at 06:32:45PM -0500 schrieb Dale:
>> Frank Steinmetzger wrote:
>>> <<>>
>>>
>>> When formatting file systems, I usually lower the number of inodes from the 
>>> default value to gain storage space. The default is one inode per 16 kB of 
>>> FS size, which gives you 60 million inodes per TB. In practice, even one 
>>> million per TB would be overkill in a use case like Dale’s media storage.¹ 
>>> Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB, 
>>> not 
>>> counting extra control metadata and ext4 redundancies.
>> If I ever rearrange my
>> drives again and can change the file system, I may reduce the inodes at
>> least on the ones I only have large files on.  Still tho, given I use
>> LVM and all, maybe that isn't a great idea.  As I add drives with LVM, I
>> assume it increases the inodes as well.
> I remember from yesterday that the manpage says that inodes are added 
> according to the bytes-per-inode value.
>
>> I wonder.  Is there a way to find out the smallest size file in a
>> directory or sub directory, largest files, then maybe a average file
>> size???
> The 20 smallest:
> `find -type f -print0 | xargs -0 stat -c '%s %n' | sort -n | head -n 20`
>
> The 20 largest: either use tail instead of head or reverse sorting with -r.
> You can also first pipe the output of stat into a file so you can sort and 
> analyse the list more efficiently, including calculating averages.

When I first run this while in / itself, it occurred to me that it
doesn't specify what directory.  I thought maybe changing to the
directory I want it to look at would work but get this: 


root@fireball /home/dale/Desktop/Crypt # `find -type f -print0 | xargs
-0 stat -c '%s %n' | sort -n | head -n 20`
-bash: 2: command not found
root@fireball /home/dale/Desktop/Crypt #


It works if I'm in the / directory but not when I'm cd'd to the
directory I want to know about.  I don't see a spot to change it.  Ideas.

>> I thought about du but given the number of files I have here,
>> it would be a really HUGE list of files.  Could take hours or more too. 
> I use a “cache” of text files with file listings of all my external drives. 
> This allows me to glance over my entire data storage without having to plug 
> in any drive. It uses tree underneath to get the list:
>
> `tree -afx -DFins --dirsfirst --du --timefmt "%Y-%m-%d %T"`
>
> This gives me a list of all directories and files, with their full path, 
> date and size information and accumulated directory size in a concise 
> format. Add -pug to also include permissions.
>

Save this for later use.  ;-)

Dale

:-)  :-) 

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

[Frank Steinmetzger]

Am Wed, Apr 19, 2023 at 06:09:15PM -0700 schrieb Mark Knecht:
> > I wonder.  Is there a way to find out the smallest size file in a
> directory or sub directory, largest files, then maybe a average file
> size???  I thought about du but given the number of files I have here, it
> would be a really HUGE list of files.  Could take hours or more too.  This
> is what KDE properties shows.
> 
> I'm sure there are more accurate ways but
> 
> sudo ls -R / | wc

Number of directories (not accounting for symlinks):
find -type d | wc -l

Number of files (not accounting for symlinks):
find -type f | wc -l

> give you the number of lines returned from the ls command. It's not perfect
> as there are blank lines in the ls but it's a start.
> 
> My desktop machine has about 2.2M files.
> 
> Again, there are going to be folks who can tell you how to remove blank
> lines and other cruft but it's a start.

Or not produce them in the first place. ;-)

> Only takes a minute to run on my Ryzen 9 5950X. YMMV.

It’s not a question of the processor, but of the storage device. And if your 
cache, because the second run will probably not use the device at all.

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

Bosses are like timpani: the more hollow they are, the louder they sound.


signature.asc
Description: PGP signature

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

[Frank Steinmetzger]

Am Wed, Apr 19, 2023 at 06:32:45PM -0500 schrieb Dale:
> Frank Steinmetzger wrote:
> > <<>>
> >
> > When formatting file systems, I usually lower the number of inodes from the 
> > default value to gain storage space. The default is one inode per 16 kB of 
> > FS size, which gives you 60 million inodes per TB. In practice, even one 
> > million per TB would be overkill in a use case like Dale’s media storage.¹ 
> > Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB, 
> > not 
> > counting extra control metadata and ext4 redundancies.
> 
> If I ever rearrange my
> drives again and can change the file system, I may reduce the inodes at
> least on the ones I only have large files on.  Still tho, given I use
> LVM and all, maybe that isn't a great idea.  As I add drives with LVM, I
> assume it increases the inodes as well.

I remember from yesterday that the manpage says that inodes are added 
according to the bytes-per-inode value.

> I wonder.  Is there a way to find out the smallest size file in a
> directory or sub directory, largest files, then maybe a average file
> size???

The 20 smallest:
`find -type f -print0 | xargs -0 stat -c '%s %n' | sort -n | head -n 20`

The 20 largest: either use tail instead of head or reverse sorting with -r.
You can also first pipe the output of stat into a file so you can sort and 
analyse the list more efficiently, including calculating averages.

> I thought about du but given the number of files I have here,
> it would be a really HUGE list of files.  Could take hours or more too. 

I use a “cache” of text files with file listings of all my external drives. 
This allows me to glance over my entire data storage without having to plug 
in any drive. It uses tree underneath to get the list:

`tree -afx -DFins --dirsfirst --du --timefmt "%Y-%m-%d %T"`

This gives me a list of all directories and files, with their full path, 
date and size information and accumulated directory size in a concise 
format. Add -pug to also include permissions.

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

Computers are the most congenial product of human laziness to-date.


signature.asc
Description: PGP signature

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

[eric]

On 4/19/23 21:23, Dale wrote:

Mark Knecht wrote:


> I wonder.  Is there a way to find out the smallest size file in a 
directory or sub directory, largest files, then maybe a average file 
size???  I thought about du but given the number of files I have here, 
it would be a really HUGE list of files. Could take hours or more 
too.  This is what KDE properties shows.


I'm sure there are more accurate ways but

sudo ls -R / | wc

give you the number of lines returned from the ls command. It's not 
perfect as there are blank lines in the ls but it's a start.


My desktop machine has about 2.2M files.

Again, there are going to be folks who can tell you how to remove 
blank lines and other cruft but it's a start.


Only takes a minute to run on my Ryzen 9 5950X. YMMV.



I did a right click on the directory in Dolphin and selected 
properties.  It told me there is a little over 55,000 files.  Some 1,100 
directories, not sure if directories use inodes or not. Basically, there 
is a little over 56,000 somethings on that file system.  I was curious 
what the smallest file is and the largest. No idea how to find that 
really.  Even du separates by directory not individual files regardless 
of directory.  At least the way I use it anyway.


If I ever have to move things around again, I'll likely start a thread 
just for figuring out the setting for inodes.  I'll likely know more 
about the number of files too.


Dale

:-)  :-)


If you do not mind using graphical solutions, Filelight can help you 
easily visualize where your largest directories and files are residing.


https://packages.gentoo.org/packages/kde-apps/filelight

Visualise disk usage with interactive map of concentric, segmented rings 


Eric

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

[Dale]

Mark Knecht wrote:
>
> > I wonder.  Is there a way to find out the smallest size file in a
> directory or sub directory, largest files, then maybe a average file
> size???  I thought about du but given the number of files I have here,
> it would be a really HUGE list of files.  Could take hours or more
> too.  This is what KDE properties shows.
>
> I'm sure there are more accurate ways but 
>
> sudo ls -R / | wc
>
> give you the number of lines returned from the ls command. It's not
> perfect as there are blank lines in the ls but it's a start.
>
> My desktop machine has about 2.2M files.
>
> Again, there are going to be folks who can tell you how to remove
> blank lines and other cruft but it's a start.
>
> Only takes a minute to run on my Ryzen 9 5950X. YMMV.
>

I did a right click on the directory in Dolphin and selected
properties.  It told me there is a little over 55,000 files.  Some 1,100
directories, not sure if directories use inodes or not.  Basically,
there is a little over 56,000 somethings on that file system.  I was
curious what the smallest file is and the largest.  No idea how to find
that really.  Even du separates by directory not individual files
regardless of directory.  At least the way I use it anyway. 

If I ever have to move things around again, I'll likely start a thread
just for figuring out the setting for inodes.  I'll likely know more
about the number of files too. 

Dale

:-)  :-) 

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

[Mark Knecht]

> I wonder.  Is there a way to find out the smallest size file in a
directory or sub directory, largest files, then maybe a average file
size???  I thought about du but given the number of files I have here, it
would be a really HUGE list of files.  Could take hours or more too.  This
is what KDE properties shows.

I'm sure there are more accurate ways but

sudo ls -R / | wc

give you the number of lines returned from the ls command. It's not perfect
as there are blank lines in the ls but it's a start.

My desktop machine has about 2.2M files.

Again, there are going to be folks who can tell you how to remove blank
lines and other cruft but it's a start.

Only takes a minute to run on my Ryzen 9 5950X. YMMV.

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

[Dale]

Frank Steinmetzger wrote:
> <<>>
>
> When formatting file systems, I usually lower the number of inodes from the 
> default value to gain storage space. The default is one inode per 16 kB of 
> FS size, which gives you 60 million inodes per TB. In practice, even one 
> million per TB would be overkill in a use case like Dale’s media storage.¹ 
> Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB, not 
> counting extra control metadata and ext4 redundancies.
>
> The defaults are set in /etc/mke2fs.conf. It also contains some alternative 
> values of bytes-per-inode for certain usage types. The type largefile 
> allocates one inode per 1 MB, giving you 1 million inodes per TB of space. 
> Since ext4 is much more efficient with inodes than ext3, it is even content 
> with 4 MB per inode (type largefile4), giving you 250 k inodes per TB.
>
> For root partitions, I tend to allocate 1 million inodes, maybe some more 
> for a full Gentoo-based desktop due to the portage tree’s sheer number of 
> small files. My Surface Go’s root (Arch linux, KDE and some texlive) uses 
> 500 k right now.
>
>
> ¹ Assuming one inode equals one directory or unfragmented file on ext4.
> I’m not sure what the allocation size limit for one inode is, but it is 
> *very* large. Ext3 had a rather low limit, which is why it was so slow with 
> big files. But that was one of the big improvements in ext4’s extended 
> inodes, at the cost of double inode size to house the required metadata.
>


This is interesting.  I have been buying 16TB drives recently.  After
all, with this fiber connection and me using torrents, I can fill up a
drive pretty fast, but I am slowing down as I'm no longer needing to
find more stuff to download.  Even 10GB per TB can add up.  For a 16TB
drive, that's 160GBs at least.  That's quite a few videos.  I didn't
realize it added up that fast.  Percentage wise it isn't a lot but given
the size of the drives, it does add up quick.  If I ever rearrange my
drives again and can change the file system, I may reduce the inodes at
least on the ones I only have large files on.  Still tho, given I use
LVM and all, maybe that isn't a great idea.  As I add drives with LVM, I
assume it increases the inodes as well.  If so, then reducing inodes
should be OK.  If not, I may increase drives until it has so many large
files it still runs out of inodes.  I suspect it adds inodes when I
expand the file system tho and I can adjust without worrying about it. 
I just have to set it when I first create the file system I guess.

This is my current drive setup. 


root@fireball / # pvs -O vg_name
  PV VG Fmt  Attr PSize    PFree
  /dev/sda7  OS lvm2 a--  <124.46g 21.39g
  /dev/sdf1  backup lvm2 a--   698.63g 0
  /dev/sde1  crypt  lvm2 a--    14.55t 0
  /dev/sdb1  crypt  lvm2 a--    14.55t 0
  /dev/sdh1  datavg lvm2 a--    12.73t 0
  /dev/sdc1  datavg lvm2 a--    <9.10t 0
  /dev/sdi1  home   lvm2 a--    <7.28t 0
root@fireball / #


The one marked crypt is the one that is mostly large video files.  The
one marked datavg is where I store torrents.  Let's not delve to deep
into that tho.  ;-)  As you can see, crypt has two 16TB drives now and
I'm about 90% full.  I plan to expand next month if possible.  It'll be
another 16TB drive when I do.  So, that will be three 16TB drives. 
About 43TBs.  Little math, 430GB of space for inodes.  That added up
quick. 

I wonder.  Is there a way to find out the smallest size file in a
directory or sub directory, largest files, then maybe a average file
size???  I thought about du but given the number of files I have here,
it would be a really HUGE list of files.  Could take hours or more too. 
This is what KDE properties shows.

26.1 TiB (28,700,020,905,777)

55,619 files, 1,145 sub-folders

Little math. Average file size is 460MBs. So, I wonder what all could be
changed and not risk anything??? I wonder if that is accurate enough???

Interesting info.

Dale

:-) :-)

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

[Frank Steinmetzger]

Am Wed, Apr 19, 2023 at 01:00:33PM -0700 schrieb Mark Knecht:


> I think technically they default to the physical block size internally
> and the earlier ones, attempting to be more compatible with HDDs,
> had 4K blocks. Some of the newer chips now have 16K blocks but
> still support 512B Logical Block Addressing.
> 
> All of these devices are essentially small computers. They have internal
> controllers, DRAM caches usually in the 1-2GB sort of range but getting
> larger.

Actually, cheap(er) SSDs don’t have an own DRAM, but rely on the host for 
this. There is an ongoing debate in tech forums whether that is a bad thing 
or not. A RAM cache can help optimise writes by caching many small writes 
and aggregating them into larger blocks.

> The bus speeds they quote is because data is moving for the most
> part in and out of cache in the drive.

Are you talking about the pseudo SLC cache? Because AFAIK the DRAM cache has 
no influence on read performance.

> What I know I'm not sure about is how inodes factor into this.
> 
> For instance:
> 
> mark@science2:~$ ls -i
> 35790149  000_NOT_BACKED_UP
> 33320794  All_Files.txt
> 7840  All_Sizes_2.txt
> 7952  All_Sizes.txt
> 33329818  All_Sorted.txt
> 33306743  ardour_deps_install.sh
> 33309917  ardour_deps_remove.sh
> 33557560  Arena_Chess
> 33423859  Astro_Data
> 33560973  Astronomy
> 33423886  Astro_science
> 33307443 'Backup codes - Login.gov.pdf'
> 33329080  basic-install.sh
> 33558634  bin
> 33561132  biosim4_functions.txt
> 33316157  Boot_Config.txt
> 33560975  Builder
> 8822  CFL_88_F_Bright_Syn.xsc
> 
> If the inodes are on the disk then how are they
> stored? Does a single inode occupy a physical
> block? A 512 byte LBA? Something else?

man mkfs.ext4 says:
[…] the default inode size is 256 bytes for most file systems, except for 
small file systems where the inode size will be 128 bytes. […]

And if a file is small enough, it can actually fit inside the inode itself, 
saving the expense of another FS sector.


When formatting file systems, I usually lower the number of inodes from the 
default value to gain storage space. The default is one inode per 16 kB of 
FS size, which gives you 60 million inodes per TB. In practice, even one 
million per TB would be overkill in a use case like Dale’s media storage.¹ 
Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB, not 
counting extra control metadata and ext4 redundancies.

The defaults are set in /etc/mke2fs.conf. It also contains some alternative 
values of bytes-per-inode for certain usage types. The type largefile 
allocates one inode per 1 MB, giving you 1 million inodes per TB of space. 
Since ext4 is much more efficient with inodes than ext3, it is even content 
with 4 MB per inode (type largefile4), giving you 250 k inodes per TB.

For root partitions, I tend to allocate 1 million inodes, maybe some more 
for a full Gentoo-based desktop due to the portage tree’s sheer number of 
small files. My Surface Go’s root (Arch linux, KDE and some texlive) uses 
500 k right now.


¹ Assuming one inode equals one directory or unfragmented file on ext4.
I’m not sure what the allocation size limit for one inode is, but it is 
*very* large. Ext3 had a rather low limit, which is why it was so slow with 
big files. But that was one of the big improvements in ext4’s extended 
inodes, at the cost of double inode size to house the required metadata.

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

FINE: Tax for doing wrong.  TAX: Fine for doing fine.


signature.asc
Description: PGP signature

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

[Mark Knecht]

On Wed, Apr 19, 2023 at 12:39 PM Nikos Chantziaras  wrote:
>
> On 19/04/2023 22:26, Dale wrote:
> > So for future reference, let it format with the default?  I'm also
> > curious if when it creates the file system it will notice this and
> > adjust automatically. It might.  Maybe?
>
> AFAIK, SSDs will internally convert to 4096 in their firmware even if
> they report a physical sector size of 512 through SMART. Just a
> compatibility thing. So formatting with 4096 is fine and gets rid of the
> internal conversion.

I suspect this is right, or has been mostly right in the past.

I think technically they default to the physical block size internally
and the earlier ones, attempting to be more compatible with HDDs,
had 4K blocks. Some of the newer chips now have 16K blocks but
still support 512B Logical Block Addressing.

All of these devices are essentially small computers. They have internal
controllers, DRAM caches usually in the 1-2GB sort of range but getting
larger. The bus speeds they quote is because data is moving for the most
part in and out of cache in the drive.

In Dale's case, if he has a 4K file system block size then it's going to
send
4K to the drive and the drive will write 8 512 byte writes to put it in
flash.

If I have the same 4K file system block size I send 4K to the drive but
my physical block size is 4K so it's a single write cycle to get it
into flash.

What I *think* is true is that any time your file system block size is
smaller than the physical block size on the storage element then
simplistically you have the risk of write amplification.

What I know I'm not sure about is how inodes factor into this.

For instance:

mark@science2:~$ ls -i
35790149  000_NOT_BACKED_UP
33320794  All_Files.txt
7840  All_Sizes_2.txt
7952  All_Sizes.txt
33329818  All_Sorted.txt
33306743  ardour_deps_install.sh
33309917  ardour_deps_remove.sh
33557560  Arena_Chess
33423859  Astro_Data
33560973  Astronomy
33423886  Astro_science
33307443 'Backup codes - Login.gov.pdf'
33329080  basic-install.sh
33558634  bin
33561132  biosim4_functions.txt
33316157  Boot_Config.txt
33560975  Builder
8822  CFL_88_F_Bright_Syn.xsc

If the inodes are on the disk then how are they
stored? Does a single inode occupy a physical
block? A 512 byte LBA? Something else?

I have no clue.

>
> I believe Windows always uses 4096 by default and thus it's reasonable
> to assume that most SSDs are aware of that.
>

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

[Dale]

Mark Knecht wrote:
>
>
> On Wed, Apr 19, 2023 at 10:59 AM Dale  > wrote:
> >
> > Peter Humphrey wrote:
> > > On Wednesday, 19 April 2023 09:00:33 BST Nikos Chantziaras wrote:
> > >
> > >> With my HDD:
> > >>
> > >>    # smartctl -x /dev/sda | grep -i 'sector size'
> > >>    Sector Sizes:     512 bytes logical, 4096 bytes physical
> > > Or, with an NVMe drive:
> > >
> > > # smartctl -x /dev/nvme1n1 | grep -A2 'Supported LBA Sizes'
> > > Supported LBA Sizes (NSID 0x1)
> > > Id Fmt  Data  Metadt  Rel_Perf
> > >  0 +     512       0         0
> > >
> > > :)
> > >
> >
> > When I run that command, sdd is my SDD drive, ironic I know.  Anyway, it
> > doesn't show block sizes.  It returns nothing.
> >
> > root@fireball / # smartctl -x /dev/sdd  | grep -A2 'Supported LBA Sizes'
> > root@fireball / #
>
> Note that all of these technologies, HDD, SDD, M.2, report different
> things
> and don't always report them the same way. This is an SDD in my 
> Plex backup server:
>
> mark@science:~$ sudo smartctl -x /dev/sdb
> [sudo] password for mark:  
> smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-69-generic] (local
> build)
> Copyright (C) 2002-20, Bruce Allen, Christian Franke,
> www.smartmontools.org 
>
> === START OF INFORMATION SECTION ===
> Model Family:     Crucial/Micron Client SSDs
> Device Model:     CT250MX500SSD1
> Serial Number:    1905E1E79C72
> LU WWN Device Id: 5 00a075 1e1e79c72
> Firmware Version: M3CR023
> User Capacity:    250,059,350,016 bytes [250 GB]
> Sector Sizes:     512 bytes logical, 4096 bytes physical
>
> In my case the physical block is 4096 bytes but 
> addressable in 512 byte blocks. It appears that
> yours is 512 byte physical blocks.
>
> [QUOTE]
> === START OF INFORMATION SECTION ===
> Model Family: Samsung based SSDs
> Device Model: Samsung SSD 870 EVO 500GB
> Serial Number:    S6PWNXXX
> LU WWN Device Id: 5 002538 XX
> Firmware Version: SVT01B6Q
> User Capacity:    500,107,862,016 bytes [500 GB]
> Sector Size:  512 bytes logical/physica
> [QUOTE]


So for future reference, let it format with the default?  I'm also
curious if when it creates the file system it will notice this and
adjust automatically. It might.  Maybe?

Dale

:-)  :-) 

P. S. Dang squirrels got in my greenhouse and dug up my seedlings. 
Squirrel hunting is next on my agenda.  :-@

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

[Mark Knecht]

On Wed, Apr 19, 2023 at 10:59 AM Dale  wrote:
>
> Peter Humphrey wrote:
> > On Wednesday, 19 April 2023 09:00:33 BST Nikos Chantziaras wrote:
> >
> >> With my HDD:
> >>
> >># smartctl -x /dev/sda | grep -i 'sector size'
> >>Sector Sizes: 512 bytes logical, 4096 bytes physical
> > Or, with an NVMe drive:
> >
> > # smartctl -x /dev/nvme1n1 | grep -A2 'Supported LBA Sizes'
> > Supported LBA Sizes (NSID 0x1)
> > Id Fmt  Data  Metadt  Rel_Perf
> >  0 + 512   0 0
> >
> > :)
> >
>
> When I run that command, sdd is my SDD drive, ironic I know.  Anyway, it
> doesn't show block sizes.  It returns nothing.
>
> root@fireball / # smartctl -x /dev/sdd  | grep -A2 'Supported LBA Sizes'
> root@fireball / #

Note that all of these technologies, HDD, SDD, M.2, report different things
and don't always report them the same way. This is an SDD in my
Plex backup server:

mark@science:~$ sudo smartctl -x /dev/sdb
[sudo] password for mark:
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-69-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron Client SSDs
Device Model: CT250MX500SSD1
Serial Number:1905E1E79C72
LU WWN Device Id: 5 00a075 1e1e79c72
Firmware Version: M3CR023
User Capacity:250,059,350,016 bytes [250 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical

In my case the physical block is 4096 bytes but
addressable in 512 byte blocks. It appears that
yours is 512 byte physical blocks.

[QUOTE]
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 870 EVO 500GB
Serial Number:S6PWNXXX
LU WWN Device Id: 5 002538 XX
Firmware Version: SVT01B6Q
User Capacity:500,107,862,016 bytes [500 GB]
Sector Size:  512 bytes logical/physica
[QUOTE]

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

[Dale]

Peter Humphrey wrote:
> On Wednesday, 19 April 2023 09:00:33 BST Nikos Chantziaras wrote:
>
>> With my HDD:
>>
>># smartctl -x /dev/sda | grep -i 'sector size'
>>Sector Sizes: 512 bytes logical, 4096 bytes physical
> Or, with an NVMe drive:
>
> # smartctl -x /dev/nvme1n1 | grep -A2 'Supported LBA Sizes'
> Supported LBA Sizes (NSID 0x1)
> Id Fmt  Data  Metadt  Rel_Perf
>  0 + 512   0 0
>
> :)
>

When I run that command, sdd is my SDD drive, ironic I know.  Anyway, it
doesn't show block sizes.  It returns nothing.

root@fireball / # smartctl -x /dev/sdd  | grep -A2 'Supported LBA Sizes'
root@fireball / #

This is the FULL output, in case it is hidden somewhere grep and I can't
find.  Keep in mind, this is a blank drive with no partitions or anything. 

root@fireball / # smartctl -x /dev/sdd
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.14.15-gentoo] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 870 EVO 500GB
Serial Number:    S6PWNXXX
LU WWN Device Id: 5 002538 XX
Firmware Version: SVT01B6Q
User Capacity:    500,107,862,016 bytes [500 GB]
Sector Size:  512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:  2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is:    In smartctl database 7.3/5440
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Apr 19 12:57:03 2023 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x80) Offline data collection activity
    was never started.
    Auto Offline Data Collection:
Enabled.
Self-test execution status:  (   0) The previous self-test routine
completed
    without error or no self-test
has ever
    been run.
Total time to complete Offline
data collection:    (    0) seconds.
Offline data collection
capabilities:    (0x53) SMART execute Offline immediate.
    Auto Offline data collection
on/off support.
    Suspend Offline collection upon new
    command.
    No Offline surface scan supported.
    Self-test supported.
    No Conveyance Self-test supported.
    Selective Self-test supported.
SMART capabilities:    (0x0003) Saves SMART data before entering
    power-saving mode.
    Supports SMART auto save timer.
Error logging capability:    (0x01) Error logging supported.
    General Purpose Logging supported.
Short self-test routine
recommended polling time:    (   2) minutes.
Extended self-test routine
recommended polling time:    (  85) minutes.
SCT capabilities:  (0x003d) SCT Status supported.
    SCT Error Recovery Control
supported.
    SCT Feature Control supported.
    SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   PO--CK   100   100   010    -    0
  9 Power_On_Hours  -O--CK   099   099   000    -    75
 12 Power_Cycle_Count   -O--CK   099   099   000    -    3
177 Wear_Leveling_Count PO--C-   100   100   000    -    0
179 Used_Rsvd_Blk_Cnt_Tot   PO--C-   100   100   010    -    0
181 Program_Fail_Cnt_Total  -O--CK   100   100   010    -    0
182 Erase_Fail_Count_Total  -O--CK   100   100   010    -    0
183 Runtime_Bad_Block   PO--C-   100   100   010    -    0
187 Uncorrectable_Error_Cnt -O--CK   100   100   000    -    0
190 Airflow_Temperature_Cel -O--CK   077   069   000    -    23
195 ECC_Error_Rate  -O-RC-   200   200   000    -    0
199 CRC_Error_Count -OSRCK   100   100   000    -    0
235 POR_Recovery_Count  -O--C-   099   099   000    -    1
241 Total_LBAs_Written  -O--CK   100   100   000    -    0
    ||_ K auto-keep
   

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

[Mark Knecht]

On Wed, Apr 19, 2023 at 3:35 AM Peter Humphrey 
wrote:
>
> On Wednesday, 19 April 2023 09:00:33 BST Nikos Chantziaras wrote:
>
> > With my HDD:
> >
> ># smartctl -x /dev/sda | grep -i 'sector size'
> >Sector Sizes: 512 bytes logical, 4096 bytes physical
>
> Or, with an NVMe drive:
>
> # smartctl -x /dev/nvme1n1 | grep -A2 'Supported LBA Sizes'
> Supported LBA Sizes (NSID 0x1)
> Id Fmt  Data  Metadt  Rel_Perf
>  0 + 512   0 0
>

That command, on my system anyway, does pick up all the
LBA sizes:

1) Windows - 1TB Sabrent:

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
0 + 512   0 2
1 -4096   0 1

Data Units Read:8,907,599 [4.56 TB]
Data Units Written: 4,132,726 [2.11 TB]
Host Read Commands: 78,849,158
Host Write Commands:55,570,509

Error Information (NVMe Log 0x01, 16 of 63 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc  LBA  NSIDVS
 0   1406 0  0x600b  0x4004  0x0280 0 -

2) Kubuntu - 1TB Crucial

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
0 + 512   0 1
1 -4096   0 0

Data Units Read:28,823,498 [14.7 TB]
Data Units Written: 28,560,888 [14.6 TB]
Host Read Commands: 137,865,594
Host Write Commands:209,406,594

Error Information (NVMe Log 0x01, 16 of 16 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc  LBA  NSIDVS
 0   1735 0  0x100c  0x4005  0x0280 0 -

3) Scratch pad - 128GB SSSTC (No name) M.2 chip mounted on Joylifeboard
PCIe card

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
0 + 512   0 0

Data Units Read:363,470 [186 GB]
Data Units Written: 454,447 [232 GB]
Host Read Commands: 2,832,367
Host Write Commands:2,833,717

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

NOTE: When I first got interested in M.2 I bought a PCI Express
card and an M.2 chip just to use for a while with Astrophotography
files which tend to be 24MB coming out of my camera but grow
to possibly 1GB as processing occurs. Total cost was about
$30 and might be a possible solution for Gentoo users who
want a faster scratch pad for system updates. Even this
second rate hardware has been reliable and it pretty fast:

https://www.amazon.com/gp/product/B09K4YXN33
https://www.amazon.com/gp/product/B08ZB6YVPW

mark@science2:~$ sudo hdparm -tT /dev/nvme2n1
/dev/nvme2n1:
Timing cached reads:   48164 MB in  1.99 seconds = 24144.06 MB/sec
Timing buffered disk reads: 1210 MB in  3.00 seconds = 403.08 MB/sec
mark@science2:~$

Although not as fast as M.2 on the MB where the Sabrent M.2 blows
away the Crucial M.2

mark@science2:~$ sudo hdparm -tT /dev/nvme0n1

/dev/nvme0n1:
Timing cached reads:   47660 MB in  1.99 seconds = 23890.55 MB/sec
Timing buffered disk reads: 5452 MB in  3.00 seconds = 1817.10 MB/sec
mark@science2:~$ sudo hdparm -tT /dev/nvme1n1

/dev/nvme1n1:
Timing cached reads:   47310 MB in  1.99 seconds = 23714.77 MB/sec
Timing buffered disk reads: 1932 MB in  3.00 seconds = 643.49 MB/sec
mark@science2:~$

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

[Peter Humphrey]

On Wednesday, 19 April 2023 09:00:33 BST Nikos Chantziaras wrote:

> With my HDD:
> 
># smartctl -x /dev/sda | grep -i 'sector size'
>Sector Sizes: 512 bytes logical, 4096 bytes physical

Or, with an NVMe drive:

# smartctl -x /dev/nvme1n1 | grep -A2 'Supported LBA Sizes'
Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 + 512   0 0

:)

-- 
Regards,
Peter.

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

[Dale]

Nikos Chantziaras wrote:
> On 19/04/2023 04:45, Dale wrote:
>> 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
>
> I believe this only shows the lifetime writes to that particular
> filesystem since it's been created?
>
> You can use smartctl here too. At least on my HDD, the HDD's firmware
> keeps tracks of the lifetime logical sectors written. Logical sectors
> are 512 bytes (physical are 4096). The logical sector size is also
> shown by smartctl.
>
> With my HDD:
>
>   # smartctl -x /dev/sda | grep -i 'sector size'
>   Sector Sizes: 512 bytes logical, 4096 bytes physical
>
> Then to get the total logical sectors written:
>
>   # smartctl -x /dev/sda | grep -i 'sectors written'
>   0x01  0x018  6 37989289142  ---  Logical Sectors Written
>
> Converting that to terabytes written with "bc -l":
>
>   37988855446 * 512 / 1024^4
>   17.68993933033198118209
>
> Almost 18TB.
>
>
>


I'm sure it is since the file system was created.  Look at the year
tho.  It's about 11 years ago when I first built this rig.  If I've only
written that amount of data to my current drive over the last 11 years,
the SSD drive should last for many, MANY, years, decades even.  At this
point, I should worry more about something besides it running out of
write cycles.  LOL  I'd think technology changes will bring it to its
end of life rather than write cycles. 

Eventually, I'll have time to put it to use.  To much going on right now
tho. 

Dale

:-)  :-) 

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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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] Re: Finally got a SSD drive to put my OS on

[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

:-)  :-)