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.
