Antw: [EXT] Re: [systemd‑devel] the need for a discoverable sub‑volumes specification

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 19.11.2021 um 10:17
in
Nachricht <YZdrlBiIK3rt7l0z@gardel-login>:
> On Do, 18.11.21 14:51, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:
> 
>> How to do swapfiles?
> 
> Is this really a concept that deserves too much attention? I mean, I
> have the suspicion that half the benefit of swap space is that it can
> act as backing store for hibernation. But swap files are icky for that
> since that means the resume code has to mount the fs first, but given
> the fs is dirty during the hibernation state this is highly problematic.
> 
> Hence, I have the suspicion that if you do swap you should probably do
> swap partitions, not swap files, because it can cover all usecase:
> paging *and* hibernation.

Out of curiosity: What about swap LVs, possibly thin-provisioned ones?

> 
>> Currently I'm creating a "swap" subvolume in the top‑level of the file
>> system and /etc/fstab looks like this
>>
>> UUID=$FSUUID    /var/swap               btrfs   noatime,subvol=swap 0 0
>> /var/swap/swapfile1 none swap defaults 0 0
>>
>> This seems to work reliably after hundreds of boots.
>>
>> a. Is this naming convention for the subvolume adequate? Seems like it
>> can just be "swap" because the GPT method is just a single partition
>> type GUID that's shared by multiboot Linux setups, i.e. not arch or
>> distro specific
> 
> I'd still put it one level down, and marke it with some non‑typical
> character so that it is less likely to clash with anything else.
> 
>> b. Is the mount point, /var/swap, OK?
> 
> I see no reason why not.
> 
>> c. What should the additional naming convention be for the swapfile
>> itself so swapon happens automatically?
> 
> To me it appears these things should be distinct: if automatic
> activation of swap files is desirable, then there should probably be a
> systemd generator that finds all suitable files in /var/swap/ and
> generates .swap units for them. This would then work with any kind of
> setup, i.e. independently of the btrfs auto‑discovery stuff. The other
> thing would be the btrfs auto‑disocvery to then actually mount
> something there automatically.
> 
>> Also, instead of /@auto/ I'm wondering if we could have
>> /x‑systemd.auto/ ? This makes it more clearly systemd's namespace, and
>> while I'm a big fan of the @ symbol for typographic history reasons,
>> it's being used in the subvolume/snapshot regimes rather haphazardly
>> for different purposes which might be confusing? e.g. Timeshift
>> expects subvolumes it manages to be prefixed with @. Meanwhile SUSE
>> uses @ for its (visible) root subvolume in which everything else goes.
>> And still ZFS uses @ for their (read‑only) snapshots.
> 
> I try to keep the "systemd" name out of entirely generic specs, since
> there are some people who have an issue with that. i.e. this way we
> tricked even Devuan to adopt /etc/os‑release and the /run/ hierarchy,
> since they probably aren't even aware that these are systemd things.
> 
> Other chars could be used too: /+auto/ sounds OK to me too. or
> /_auto/, or /=auto/ or so.
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin