I would ask whether you realize you’re on a linux community, but you referred to a man page as a wiki article so you are clearly lost.
The first paragraph past the link is a summary of the function of the program.
fstrim is used on a mounted filesystem to discard (or “trim”) blocks which are not in use by the filesystem. This is useful for solid-state drives (SSDs) and thinly-provisioned storage.
Both links referred to the manpage of it tho. Manpages typically explain the programs purpose in the first sentence. So the guy saying he doesn’t want to read a whole wiki article probably didn’t even click on the links and just assumed it was a 10k line wiki article because it’s from arch.
Good for performance. It lets the SSD know when something isn’t needed anymore and means when something comes to write to the same area it doesn’t have to do a load of internal faffing (garbage collection) before it can actually write
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.
fstrim is used on a mounted filesystem to discard (or "trim")
blocks which are not in use by the filesystem. This is useful for
solid-state drives (SSDs) and thinly-provisioned storage.
By default, fstrim will discard all unused blocks in the
filesystem. Options may be used to modify this behavior based on
range or size, as explained below.
The mountpoint argument is the pathname of the directory where
the filesystem is mounted and is required when -A, -a, --fstab,
or --all are unspecified.
Running fstrim frequently, or even using mount -o discard, might
negatively affect the lifetime of poor-quality SSD devices. For
most desktop and server systems a sufficient trimming frequency
is once a week. Note that not all devices support a queued trim,
so each trim command incurs a performance penalty on whatever
else might be trying to use the disk at the time.
For instance, why would unused blocks not be discarded? And what does “discarded” even mean in this context? But it does recommend against using it for SSDs so I think I’ll skip it.
Systemd does everything including cron functionality. Timers are the Systemd equivalent of lines in /etc/crontab. Arch doesn’t even have a cron application pre-installed. (But does have Systemd.) So in short, timers are kindof the idiomatic way to run things on a schedule in Arch.
The way I understand it, it’s an automated job that sends the “trim” command to SSDs to discard all the blocks that have been marked as unused by the filesystem. My knowledge is a little patchy so I’m probably missing some important details…
When you go to delete something on an SSD, it’s simply just marked as being deleted. The file still technically occupies space on the SSD and the SSD will never simply overwrite space that has a deleted file on it.
So… by enabling the service, systemd will automatically send the trim command that tells the SSD to empty out all the space occupied by files marked as deleted which allows the SSD to reuse said space.
Nothings stopping you. It achieves the same thing. Some people might just prefer this since it’s easier and gets logged in the systemd journal? The Arch wiki lists some nice benefits of using systemd timers as a replacement to cron jobs.
The what?
It’s a systemd timer included within Arch that runs fstrim every week.
and what does that achieve?
It’s a systemd timer included within Arch that runs fstrim every week.
wow such a great, short and understandable explanation that doesn’t link to a wiki article that no one will voluntarily read
I would ask whether you realize you’re on a linux community, but you referred to a
manpage as a wiki article so you are clearly lost.The first paragraph past the link is a summary of the function of the program.
I think he is referring to the arch wiki
Both links referred to the manpage of it tho. Manpages typically explain the programs purpose in the first sentence. So the guy saying he doesn’t want to read a whole wiki article probably didn’t even click on the links and just assumed it was a 10k line wiki article because it’s from arch.
no it’s a manpage
It’s a systemd timer included within Arch that runs fstrim every week.
Fstrim? Damn near killed 'em.
Good for performance. It lets the SSD know when something isn’t needed anymore and means when something comes to write to the same area it doesn’t have to do a load of internal faffing (garbage collection) before it can actually write
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!
Yeah, the man page doesn’t really help me out.
For instance, why would unused blocks not be discarded? And what does “discarded” even mean in this context? But it does recommend against using it for SSDs so I think I’ll skip it.
“this is useful for solid-state drives”
Where is it not recommended?
Or did I just miss something?
I guess it was recommending against frequent runs.
Can’t you set this up as a cronjob?
Systemd does everything including cron functionality. Timers are the Systemd equivalent of lines in /etc/crontab. Arch doesn’t even have a cron application pre-installed. (But does have Systemd.) So in short, timers are kindof the idiomatic way to run things on a schedule in Arch.
Specifically, it’s in the util-linux package. On Gentoo at least.
The way I understand it, it’s an automated job that sends the “trim” command to SSDs to discard all the blocks that have been marked as unused by the filesystem. My knowledge is a little patchy so I’m probably missing some important details…
When you go to delete something on an SSD, it’s simply just marked as being deleted. The file still technically occupies space on the SSD and the SSD will never simply overwrite space that has a deleted file on it.
So… by enabling the service, systemd will automatically send the trim command that tells the SSD to empty out all the space occupied by files marked as deleted which allows the SSD to reuse said space.
So why not do something like
sudo crontab -eAnd add
0 10 * * 1 root the funy commandAssuming your PC is always on at 10 am on mondays?
Nothings stopping you. It achieves the same thing. Some people might just prefer this since it’s easier and gets logged in the systemd journal? The Arch wiki lists some nice benefits of using systemd timers as a replacement to cron jobs.
Phew, I thought it would trigger the Cron Goblin