this post was submitted on 18 Oct 2023
213 points (96.9% liked)
linuxmemes
21255 readers
16 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudo
in Windows.
- No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
It's a systemd timer included within Arch that runs fstrim every week.
and what does that achieve?
It appearantly helps with SSDs so unused blocks aren't clogging things up. Not sure I fully understand what dropping unused blocks does but I guess it could help with performance?
Simplified version: SSDs or more precisely NAND flash memory has some technical quirks. You can't just overwrite stuff like you do with magnetic hard drives. You have to actually delete things. Also you can usually only delete full physical blocks.
But data rarely fits neatly into physical blocks, so instantly deleting data would mean every time you delete something that partly resides in one block, you would need to save the data in that block you want to keep, wipe the whole thing then rewrite parts of it. That's a lot of unnecessary stress on the hardware and also more work in teh writing and rewriting process.
So SSDs use a similiar approach as old magnetic hard drives. Blocks aren't physical deleted but marked as no longer used. Which works well for hard drives where you can just overwrite data, but for SSDs this is also far from optimal as with every new write you want to commit you have to pre-check if this unused part of a block is already deleted and usuable or not? In the latter case you either need to do the "save some of it, wipe the block, rewrite" oparation you tried to avoid before or simply go on and try to find another actual free block to use. Which decreases performance obviously. And at some time you would have a lot of wasted half-full blocks and would need to organize your data to reclaim these
Enter TRIM... where periodically (usually when the system is idle anyway) the blocks that are marked as deleted are checked if there's still used data in it (those are then copied to a completely free block and the whole block is wiped to free it up for the next write.
In layman's terms it's basically anolog to defragmenting a hard drive in the brackground. When the drive isn't doing anything important it spends time rearranging data only partly using a physical block to wipe the whole thing and also to wipe blocks that are completely marked as deleted to keep everything neat and organized with fully used blocks and wiped blocks available for re-use.
PS: so-called continues TRIM is available also. That will basically do the whole "everytime a part in a block is marked as deleted write the other data to a new block an wipe the whole block"-routine in real-time... but after the regular writes are done to not clog up the system. But periodic TRIM is easier on the drive and usually sufficient.
PPS: TRIM is part of the drive's set of commands. So all the data handling involved doesn't need to be handled by the file system. You just issue the TRIM command to the drive and it handles everything internally.
Thank you!