Talk:Filesystems

#SSD_TRIM_support definitely needs improvement

1) Periodic trim is already enabled by default

2) No mention of differences between periodic and continuous trim. Continuous trim is often not recommended.

3) On btrfs, discard=sync is enabled by default and using discard (or discard=sync) is discouraged

Pigeon (talk) 15:54, 6 June 2025 (UTC)

Also,  from man mount(8):

noatime

Do not update inode access times on this filesystem (e.g. for faster access on the news spool to speed up news servers). This works for all inode types (directories too), so it implies nodiratime.

Hence everything stated above renders the whole Filesystems#SSD TRIM support section mostly redundant. I am a wiki noob so i hesitate take any actions myself. What do you think? Pigeon (talk) 16:07, 6 June 2025 (UTC)

Good catch, I updated the section.

On point number 3, I am seeing that on btrfs `discard=async` is what is set to as default. Pigs (talk) 16:44, 6 June 2025 (UTC)

> On point number 3, I am seeing that on btrfs `discard=async` is what is set to as default.

Exactly. A typo on my side.

Also it seems that discard=sync is BTRFS-specific. From what i can see after doing a bit of googling continuous trim is commonly enabled with discard option so we should just not mention discard=sync in that section. Pigeon (talk) 17:24, 6 June 2025 (UTC)

I think it is reasonable to leave `discard=sync` as a user might see `discard=async` and think they should remove it. Pigs (talk) 17:43, 6 June 2025 (UTC)

the thing is that `discard=async` is also a continuous trim. It addresses main problems that synchronous trim has, but is still generally not recommended. Even Fedora, one of the main btrfs adopters, uses fstrim and does not set `discard=async` by default.

Continuous and periodic trim modes can be enabled simultaneously, this scenario is covered by the responsible developers. I think mentioning `discard=sync` as it is right now is unnecessary.

It can get complicated in the end. If the goal of this wiki is focusing on explaining how to accomplish something in nix-specific way, it would be beneficial to just link Arch Wiki that covers nearly everything when on this matter. Or if i am misunderstanding the purpose of `nixos` wiki, then we need to provide more details in this section. For example, btrfs page does not cover fstrim and `discard=async`, so we need to either be exhaustive, or not go beyond the sufficient minimum. Please, coordinate my understanding Pigeon (talk) 18:03, 6 June 2025 (UTC)

Without knowing literally anything about this context, I am seconding @Pigeon's point here, more information is better than less information. At the very least let's write up an article/section on what the two discards do, and link it here. DoggoBit (talk) 22:32, 7 June 2025 (UTC)

In my opinion, the nixos wiki should document concepts on the nix ecosystem and link to official sources for anything that isn't in the nix ecosystem. The goal here is not repeat information that is documented elsewhere. More information is not always better as it can clutter the wiki page and require more maintenance to keep the information in sync with official sources.

In this example, we should give a brief description of what discard is, link to the official source, and show how to use the discard mount option on NixOS. Pigs (talk) 05:15, 8 June 2025 (UTC)

We are in principle on the same page here. What I mean by more information is always better is that other editors that are not subject matter experts in this area (e.g. me) can always edit an article down (or move information to subpages, etc.) to make the page more readable. But we'll almost never have the knowledge to add information in.

Regarding links to the Arch Wiki, my hunch is if the Arch Wiki needed to have info about a topic, it's important enough for a user that we might need to have info too. Maybe not in the same for, maybe not to the same extent, but at least something.

Thanks for your awesome work on this! DoggoBit (talk) 15:35, 8 June 2025 (UTC)