I’m using an SSD to run endeavour os , it’s a sata installed Kingston KC 600 , it’s 256 GB …
On windows trim is enabled by default and it’s done weekly, should I enable it in endeavour os, or is it too much work?
If I were to need it, what’s the syntax for it ?
Do you use trim ? Hopefully everyone has SSDs here xD
For any SSD answer is - yes. Disable continuous, enable periodic.
Disable continuous: for all your disks remove discard option in:
/etc/fstab
Enable periodic:
systemctl enable --now fstrim.timer
Check service:
sudo systemctl status fstrim.timer
Check period settings (default should be fine: OnCalendar=weekly):
cat /usr/lib/systemd/system/fstrim.timer
Throw Kingston SSD / RAM (really anything) right in the trash, where it belongs, if you care about your data and sanity.
Here you can read about trimming and how you can enable it to be performed on a weekly basis:
https://wiki.archlinux.org/title/Solid_state_drive#TRIM
https://wiki.archlinux.org/title/Solid_state_drive#Periodic_TRIM
Thanks for the syntax, I honestly don’t care about the SSD as much, but since I paid for it I’ll use it till it breaks, perhaps I’ll buy a Samsung later on, I know that you don’t like Kingston SSDs, but not all are built the same
I read from Reddit that this is like a worse Samsung 800 series Evo(or it has similar components at least) , that and the lower number of bad reviews from Amazon made me decide to buy it, along with a huge number of good reviews in Romania, I just found out today that Kingston aren’t the best SSDs, I might not buy another one next time
Here’s proof of the better number of reviews
:
https://www.amazon.com/Kingston-KC600-512GB-SATA3-Solid/dp/B07ZDBT15M
Thanks for telling me
To put it mildly.
You’re right, some are even worse than absolute crap 
btw, reviews inside aggregators doesn’t mean anything, they can be faked, boted and bumped - so more people would buy sh*t, especially on Amazon. As well as in reverse, decent products are very easy to kill by reviews of their competitors.
Only experience or people you know and trust can be valuable advice, i think.
you wasting RAM?! how dare you waste some lovely Ramen Assistant Service
I spent way too much time reading and asking about this and it depends on model, filesystem, set-up etc. etc. and much info online is outdated (and hence wrong).
tl;dr: the defaults are sane
so if the default are “sane” nothing must be modified and I shouldn’t activate trim ?
Read all the red warnings on that page
https://wiki.archlinux.org/title/Solid_state_drive#
Does it look sane to you?
I specifically use nodiscard on all filesystems regardless of drive type. There is no good reason to use continuous discard on a desktop system. It potentially causes higher cpu use, more frequent writes to drives, and relies on filesystems sending trim commands to drive firmware which may or may not be honored depending on the firmware. Periodic trim is more than enough for desktop use. The default and supposedly “sane” settings for continuous trim via the discard mount option apply to very specific types of drives under extremely heavy use, and that is not typical for desktop systems.
Which filesystem? Two different filesystems have different discard method.
I guess you are talking about Ext4. Ext4 with discard causes the problems what you described because it has no discard async support. It is different than Btrfs.
That is why I said “defaults are sane”, because there is a list of models in the Linux kernel that behave differently, and the kernel auto-detects that. Then then it depends on the file system, and each has their own defaults. Then it depends on whether or not you put things into RAID or not. Then it depends on whether you encrypt or not. And all of these things have their own defaults that work together to make sure things work fine.
I did not say defaults are optimal if you know what you are doing. I said defaults are sane in the sense that they are safe.
Unless you know what you’re doing, I would (and did) just keep the defaults and not change the settings. SSD tech is improving and so is code handling it. There’s a lot of outdated info out there. For example, on the Linux kernel mailing list, there was this discussion back in 2012 where it was said that TRIM is not needed on modern SSD and forcing it could even degrade the drive faster: https://www.spinics.net/lists/raid/msg40916.html
If you do know what you’re doing, all the power to you then 
I am not sure what power you attribute to async as it relates to discard. Async merely allows the discard trim commands to be delayed until the drive is not as busy rather than forcing the trim commands to follow each transaction, afaik. Continuous discard is still not waranted on desktop systems for a majority of the time under both ext4 and btrfs. One could even make an argument that COW filesystems would suffer more of an impact from continuous discard since it entails more writes due to the copy on write features. I could be all wrong though. 
From the: https://btrfs.readthedocs.io/en/latest/Administration.html
…
The asynchronous mode (async) gathers extents in larger chunks before sending them to the devices for TRIM. The overhead and performance impact should be negligible compared to the previous mode and it’s supposed to be the preferred mode if needed.
If it is not necessary to immediately discard freed blocks, then the fstrim tool can be used to discard all free blocks in a batch. Scheduling a TRIM during a period of low system activity will prevent latent interference with the performance of other operations. Also, a device may ignore the TRIM command if the range is too small, so running a batch discard has a greater probability of actually discarding the blocks.
…
Async will wait until there are larger chunks before sending the trim commands, which is good. However, fstrim is still possibly better at achieving greater results and efficiency with regards to trim commands since it batches all trim commands to run at once.
Yes
In particular, creating many snapshots/subvolumes containing old versions of data results in more writes, yes.
However, you don’t necessarily have to create a subvolume/snapshot. you can store data on a root-subvolume like a “flat layer” without a CoW layer. Remember that there is a additional compression and deduplication to reduce writes.