Why is it megathread? Besides I never update - do fresh install. Which allows me fresh beginning without garbage collected through years.

1 members found this post helpful.

The original post contains the text, "This thread is not for those who choose to perform a fresh install."

I have a question.
libc update
why there is command
( cd lib64 ; rm -rf ld-linux-x86-64.so.2 )
( cd lib64 ; ln -sf ld-2.33.so ld-linux-x86-64.so.2 )
If you delete ld-linux-x86-64.so.2, all commands stop working, since there is missing library ?
Should it be without rm command and just ln ?

It's a block of dead code as explained above it. But you could give those commands when you run them from the install disk. That link lib64/ld-linux-x86-64.so.2 is not under root then but in /mnt.

(I think the rm command is there to protect against a directory called ld-linux-x86-64.so.2)

Well i am thinking when you do update on system that is running.
Isn't ln -f enough, man page says it will remove existing destination files ?

Currently i have problem when i am installing on virtual machine, and each time there is libc update, it removes this file and blocks.

You should have an executable /sbin/ldconfig. Look:
Yes, ln -sf would be enough if you knew for sure that the previous ld-linux-x86-64.so.2 were a file or a symlink (not a directory).

The only point I'd add to bassmadrigal's excellent comments about fstrim: It probably wouldn't hurt to defragment the filesystem first, via "e4defrag" or "xfs_fsr", to consolidate the files' extents. SSD derives the same benefit as spinning platters, by merging multiple-sector read operations into a single bus transfer. Doing that before running fstrim will help to make a "cleaner" volume on the SSD, plus yielding faster write response for a longer time (by providing more "clean" blocks available for immediate write).

For myself, I also omit the journal on the root partition (which contains /usr per PV's policy). On a "normal" Slackware install, the root and /usr stuff is normally more read than written. The typical candidates for journal entries are mtime/atime updates, and the "lazytime" mount option reduces that dramatically. As I understand it, including a discrete journal within a volume on the SSD potentially doubles the write-outs for any file writes, once to the journal, and once to the FS structure proper (excepting log-structured FS's, like Btrfs and F2FS).

Bear in mind, these thoughts are 6 or 7 years old, so they may approach a "cargo cult" mentality.

2 members found this post helpful.

just a quick correction on the nature of trim: sectors do not need to be "reset before re-written". The file system will happily rewrite the exact same sectors of formerly deleted files. What fstrim, or discard, does: it informs the SSD controller that those sectors can be returned to the pool of unused blocks, so that they can be re-integrated in the wear-levelling algorithm, ensuring that there is no concentration of write-operations on a small set of physical memory cells.

Your information doesn't seem to be correct. This is direct from Crucial's site explaining what trim is for (bold is my emphasis):

I did kinda combine trim and garbage collection to simplify it (since the post was long already), but multiple sites say that used blocks need to be erased before they can be written again.

well, it is correct that SSD controllers will initialize ("delete") sectors in the unused block pool, in order to save time when they are allocated and written to in the future. In that respect we are talking about the same thing. What I tried to make clear is that from the external API (the point of view of the filesystem), you can re-write any sector any time, because the SSD controller will always map it to a fresh sector from the pool of unused blocks (releasing the previously mapped sector). The trim / discard function serves to return sectors to the pool no longer in use by the file system.

Correct, but if the filesystem doesn't have any available unused/erased blocks, when the filesystem goes to write them, the flash controller needs to erase the block before it can be written to.

This is all done without knowledge from OS and is done internally from the controller of the SSD/NVMe device.

So, the sectors the filesystem sees don't need anything beyond simply deleting the file (because the filesystem doesn't know about the inner workings of the flash memory), but the blocks on the device do need to be "reset" or erased once a file is deleted before being able to be rewritten, which is all handled by the flash controller with the OS being left in the dark. If there are available erased sectors/blocks, then the controller will typically use those with little to no penalty before spending the extra time erasing other blocks so they can be written to. Trimming the device pretty much just tells the device to reset/erase all those blocks that had files deleted so they are ready to be written to whenever they're needed.

I believe it should be noted that I didn't use "sectors" anywhere in my post. I was simply talking about the data on the drive itself, not what the filesystem sees (since the filesystem doesn't deal with the actual writing of data to the device), so I don't understand what information on trim you were trying to correct.

Digging a bit deeper, the fonts still look funky but part of the problem is the TraditionalOK theme I use, which comes with the MATE packages, which I haven't downloaded or tested yet in Current.

My really big sore spot with Xfce is tooltips. I feel totally helpless that I can't disable the sumbitches. Annoying as Hell.

I agree with all that.

This is the part I tried to elaborate on. Whilst the initialization of physical memory blocks is indeed part of what is going on, the function is trimming is more fundamental. The SSD has more physical memory blocks than sectors are offered to the SATA API. They are constantly re-mapped (and potentially initialized) for wear-levelling purposes. To that end the SSD controller keeps a free list redundantly from the consumer. What is being trimmed (hence the name) - ie. kept in sync - is those redundant lists.

From the point of view of software architecture, this redundancy is an example of a -> leaky abstraction.

Not trimming (i.e. not telling the SSD controller that certain sectors can be returned to the pool) is less detrimental than people think, as long as the file system sticks more or less to the same sectors as it grows and shrinks. The worst case would be a random access pattern, because the pool of available physical memory blocks from the point of view of the SSD controller will shrink to the minimum, but never be zero, as the device has been fitted with more memory than official sectors by the manufacturer.

In the early days people sometimes gave the advice to leave a certain space empty in the partition table for the lifetime of the SSD, in order to increase the memory pool.

Over and out.

Trimming is to make sure that blocks marked as deleted are available for the flash controller to write as needed. If trimming isn't accomplished, if the drive needs to write into a space that hasn't been erased, it needs to erase it before it can write to it.

Yes, there is provisioned space that isn't available to the user to help enhance wear leveling and provide backup blocks as the individual blocks wear out and can no longer write new data, but that was far beyond the point of the post I was writing to answer the question about whether running fstrim did anything.

OP here. Perhaps the SSD trim discussion is off topic?