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

[Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>]

On Mon, Jun 24, 2019 at 02:11:03PM +0200, Lennart Poettering wrote:
> On Sa, 22.06.19 10:42, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:
> 
> > Hi,
> >
> > I've got a commit to add 'Conflicts=umount.target' to this zram
> > service based on a bug comment I cited in the comment. But I'm not
> > certain I understand if it's a good idea or necessary.
> >
> > https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel
> >
> > I figure it's plausible at shutdown time that something is swapped
> > out, and a umount before swapoff could hang (briefly or indefinitely I
> > don't know), and therefore it's probably better to cause swapoff to
> > happen before umount.
> 
> 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)?

> That said, I don't really grok zram, and not sure why there's any need
> to detach it at all. I mean, if at shutdown we lose compressed RAM
> or lose uncompressed RAM shouldn't really matter. Hence from my
> perspective there's no need for Conflicts= at all, but maybe I am
> missing something?
> 
> Zbigniew, any particular reason why you added the Conflicts= line?

It's been a while since I wrote that comment... Most likely I did it
because that's the default combination that we use for units, and I didn't
think that something different should be used for a swap service. Don't
read too much into it.

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