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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux