[systemd-devel] swap on zram service unit, using Conflicts=umount

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 25, 2019 at 10:55:27AM +0200, Lennart Poettering wrote:
> On Mo, 24.06.19 13:16, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> 
> > > So for tmpfs mounts that don't turn off DefaultDependencies= we
> > > implicit add in an After=swap.target ordering dep. The thinking was
> > > that there's no point in swapping in all data of a tmpfs because we
> > > want to detach the swap device when we are going to flush it all out
> > > right after anyway. This made quite a difference to some folks.
> >
> > But we add Conflicts=umount.target, Before=umount.target, so we do
> > swapoff on all swap devices, which means that swap in the data after all.
> > Maybe that's an error, and we should remove this, at least for
> > normal swap partitions (not files)?
> 
> We never know what kind of weird storage swap might be on, I'd
> probably leave that in, as it's really hard to figure out correctly
> when leaving swap on would be safe and when not.
> 
> Or to say this differently: if people want to micro-optimize that,
> they by all means should, but in that case they should probably drop
> in their manually crafted .swap unit with DefaultDependencies=no and
> all the ordering in place they need, and nothing else. i.e. I believe
> this kind of optimization is nothing we need to cater for in the
> generic case when swap is configured with /etc/fstab or through GPT
> enumeration.

Not swapping off would make a nice optimization. Maybe we should
invert this, and "drive" this from the other side: if we get a stop
job for the storage device, then do the swapoff. Then if there are
devices which don't need to stop, we wouldn't swapoff. This would cover
the common case of swap on partition.

I haven't really thought about the details, but in principle this
should already work, if all the dependencies are declared correctly.

> zswap is different: we know exactly that the swap data is located in
> RAM, not on complex storage, hence it's entirely safe to not
> disassemble it at all, iiuc.

Agreed. It seems that any Conflicts= (including the one I proposed) are
unnecessary/harmful.

Zbyszek