Re: swap on zram service unit, using Conflicts=umount

[Chris Murphy <lists@xxxxxxxxxxxxxxxxx>]

On Tue, Jun 25, 2019 at 3:30 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxx) 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.

I like the sound of this. The gotcha with current swap on zram units
(there are a few floating out there including this one), is they
conflate two different things: setup and teardown of the zram device,
and swapon/swapoff. What's probably better and more maintainable would
be a way to setup the zram device with a service unit, and then
specify it in /etc/fstab as a swap device so that the usual systemd
swapon/off behavior is used. Any opinion here?

(Somewhat off topic: I wish zswap was not still experimental: by
enabling zswap with an ordinary swap device, it creates a memory pool
(which you can define a percentage of total RAM to use) that's
compressed for swap before it hits the backing device. Basically, it's
like a RAM cache for swap. It'll swap to memory first, and then
overflow to a swap partition or file. It also lacks all the weird
interfaces of zram.)

https://wiki.archlinux.org/index.php/Improving_performance#Zram_or_zswap

> > 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.

OK I'll negate the commit that inserts it.


-- 
Chris Murphy
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel