Re: wait until swapoff is *actually* finished (it returns too early)?
On Thu 22 Aug 2024 at 17:21:04 (+0000), Thorsten Glaser wrote:
> Mike Castle dixit:
>
> >Does cryptdisks have the ability to display what is in use at the
> >moment? Maybe polling that before executing the stop?
>
> That’s what I would like to ask and why I sent this eMail.
Is cryptdisks_stop failing an issue? If not, just repeating it
in a slow loop until it succeeds would be one strategy.
> >I suspect that the race is that, when the the swapoff() syscall
> >returns, the kernel has indeed moved all of the content off, so that
> >part is fine... but it has not yet released whatever kind of resources
> >is has on the backing store (akin to an open file handle).
>
> My guess as well.
I'm not convinced. Finding out what needs copying back and locating
somewhere to put it is AIUI a slow process. What's much faster is
when processes themselves demand something be paged back in from
swap. I think there are "tricks" available to cause that to occur,
thus speeding up swapoff.
> >You could then control the timeout by looping no more than N times,
> >then failing a bit more gracefully than it is now.
>
> That’d be a method of last resort, same category as the sleep,
> except even worse. I’d like to find a way to prevent that.
Presumably once you have executed swapoff, you're committed to
waiting, because otherwise cryptdisks_start on the same device
would fail.
Of course, if swap /size/ is not an issue, you could have two swap
areas, and start the second before you stop the first. That way,
swapoff speed is not an issue. Well now, you /do/ have two!
Cheers,
David.
Reply to: