Code change:
Is it possible to implement mount options for swap partition? This feature could be useful for machines with SSD only drive(s). User could change to options for automatic trimming. of this feature.
I think this is what you want
I still can't figure out solution with documentation pointed out. If I put raises an error. I am using NixOS 14.12 stable. As far as I know swap partition does not have mounting point.
you may do it like this: even though, i didn't test it, but using like this should work regards, iker
Still, it would be nice if there were a more idiomatic way to accomplish that.
Sorry for long pause. After some research, setting discard on swap is NOT good idea. (see ). Setting it, would trigger trim command every time block clears, which leads to poor performance when swap is under pressure. Issue can be closed.
according to the there is a single variant, which is NOT that bad idea:
On top of the case pointed out by of doing a oneshot discard of swap space on startup, there are some situations where there really isn't much of any performance impact. As a simple example, I'm running NixOS in a VM, and the hypervisor translates TRIM/UNMAP/DISCARD commands into calls to fallocate() with the FLPUNCHHOLE flag on the host side. This ends up completing almost instantly due to how my storage stack is set up (and will in most cases where people are using file-backed VM disks), and more importantly, it can be queued on the VM side because it's on an emulated SCSI device. There's literally no measurable performance impact in this case, but there's a big impact on the host side in terms of simplifying space management. Even ignoring use of virtualization, 90% of the performance issue for inline discards in general (not just for swap space) is due to most commodity hardware not being able to queue them, which results in them having about the same impact as an FUA request. Some hardware, however (notably most SCSI and NVMe devices) can queue them, and they have very little impact on performance there.
since this issue got new visits again, i've uploaded , which is a start. I've also looked into unifying and , but it seems a lot of work if such a change doesn't get merged.
What if both and options are in use? /etc/fstab gets 2 entries: Interestingly, the nixos-generate-config options is placed in a lower part of /etc/fstab. There is hope that the first entry gets precedence. But I don't know any mean of checking . the issue still unresolved. Can you reopen, please?
I'm using nixos 21.05 and want to add the "nofail" option for swap devices that are in raid1. Options: can send a PR for a option that gets passed to . I have this and can put it up quickly. This mirrors . can send a PR for a specific option. can use , which can support arbitrary options. But then won't be reproduced correctly. Any opinions?
The approach would get my vote, as it avoids any possibility of arguments between users and developers when a user wants to use an option the developer thinks should not be used (such as the option that started all of this).

Related discussion:
text: merge = mergeEqualOption; }; <ins> nonEmptyStr = mkOptionType { name = "nonEmptyStr"; description = "non-empty string"; check = x: str.check x && builtins.match "[ tn]*" x == null; inherit (str) merge; }; </ins> strMatching = pattern: mkOptionType { name = "strMatching ${escapeNixString pattern}"; description = "string matching the pattern ${pattern}";