Seems like removing the ".eli" solved the issue. …
… whenever the machine goes to sleep (S3) - the contents are dumped into swap, however, upon waking up - the swap is always full …
An aspect may have not been well-defined. I posited that as a data point, "what is the behavior when swap is NOT encrypted", the tested hypothesis was "Does encrypting swap instigate/exacerbate the bad behavior". By eliminating encrypted swap and maintaining everything else the same (workload, suspend behavior) if it was better, then encrypted swap was a factor in the issue.With respect: not really, because the issue was not well-defined.
Based solely on the OP, agree. But reading through the rest of the questions and responses further in the thread, the fact that swap was encrypted with a one time key was interesting to me.To me, neither of those suppositions/observations make sense.
Is that key maintained across unsuspend?
Me too, but the observed behaviour implies "maybe not"I assume so.
Somehow this doesn't work for me. I remember these function buttons were a pain to get to work correctly last time I had tried.. on Thinkpads, Fn + F4
To be specific : commented out the same line with ".eli" and copied the same without the extension. Strange indeed.That is very odd.
So you edited /etc/fstab, removed the .eli, rebooted, did your typical workload, suspended, etc and it's not using swap now?
Very strange.
Sorry - I thought the reference to the text was obvious - didn't mean to imply you were saying something else.[FONT=monospace]Tracker[/FONT]: you quote me as saying just
zzz
Please don't get in the bad habit of quoting a word or phrase out of context, when I said:
Interesting - didn't know about zzz at all.Why assume a 'shortcut', let alone a shell alias? Whenever in doubt, ask man (or apropos):
zzz(8)
I suspect that there is still a reference to the .eli in rc.conf, so the system tries to swap to a device that is not mounted. That would explain why it is not used.
cat /etc/rc.conf | grep eli
doesn't return anything.To me, neither of those suppositions/observations make sense.
Yes, I didn't suspect simply removing the extension would solve the issue as well. Can't make sense of it myself. But I have now, multiple times, closed the lid and tried `sudo acpiconf -s 3` - the swap space isn't being utilized at all. I don't recall doing much else to solve this issue.is boggling.
culprit
Basics. … diagnose …
For definite, useful information about how swap is used, run:
systat -swap
…
Do not disable swap.
Has there been an opportunity?
My thought process was:
swap encrypted with one time key, laptop suspended, what happens to that key?
Is that key maintained across unsuspend? If not, then swap can be tagged in use but never cleared. If so, then swap should clear.
My simple question of "what happens if swap is not encrypted and you do everything else the same" was to get data points. But the OP's reports of "I removed the .eli so not ecrypted and not using swap anymore" is boggling.
Somehow this doesn't work for me. I remember these function buttons were a pain to get to work correctly last time I had tried.
Also tried to add my user name to operator group but seems like it won't permit - maybe it requires a restart?
> sudo pw group mod operator -m myusername
Not really. I had put haiku on old ThinkPads I have and these buttons don't work there.Fn+F4 is hard wired, like the power button. There may be one way to disable or redefine it, via devd.
Unfortunately, so am I.I'm getting used to boggledness.
"For the sake of curiosity - would it be worthwhile to enable the ".eli" extension in fstab and checking if swap comes back into use? Perhaps not now, but maybe sometime in the next few days. Might throw some light if that indeed was the, seemingly strange, culprit."
I've been running with .eli on my swap partitions for a while, across 13.x now 14.0-RELEASE, on 2 different systems.
One having 32GB the other 8GB of memory and I've never seen swap used. Both are desktops so I'm not suspending like you are so I'm guessing it may be the combination of encrypted swap and suspending that is somehow the root cause. The only way I can wrap all that up is the onetime key not getting preserved across the suspend operation so the swap can't be cleared.
… short of a proper PR process to get relevant eyes onto it, I'll be surprised if it's solvable here. …
And you've been doing the same workload as before? work work work, suspend, unsuspend, work work work?Update : Still haven't restarted the machine. Just noticed swap is now finally being utilized (via htop) - although much lesser (about 1.72GB / 8 GB as of now) - still have unused 40 GB of RAM, not sure why/when it's requiring the swap.
Sorry for the confusion here - the swap usage for 0 until yesterday.
Fwiw - it took considerable time for the swap to be utilized this time (few days) and much lesser usage(used to be full earlier). Earlier (before unencrypting the swap) the usage used to show up much faster.
not sure why/when it's requiring the swap.
I wonder if this is some data in support of encrypt key not being supported across suspend/unsuspend.
encrypted swap, one time key:
suspend, put stuff on swap with key A
unsuspend, key A is "lost" so swap is not cleared, but swap code knows space is in use and maybe now we have key B
suspend using key B, unsuspend now key B is lost, swap has stuff from key A and key B.
That almost sounds like the symptoms
Yes - only suspend,resume. To be more specific I have a (large) instance of chromium and another browser running some jupyter notebooks (among other things in the background tabs) .... besides that a few terminals open, not doing much at all there.And you've been doing the same workload as before? work work work, suspend, unsuspend, work work work?
systat -swap
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |||||||||
Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ 90\ 100|
ada0p4 7932M 1949M XXXXXXXXXXXX
Pid Username Command Swap/Total Per-Process Per-System
Yep, absolutely. I run desktops, don't do suspend/resume so I'm thinking out loud on this.That's pretty speculative;
(no pids,username,command, etc show under that)
Yep, absolutely. I run desktops, don't do suspend/resume so I'm thinking out loud on this.
What I know about the swap stuff is simply adding a .eli to the partition definition /etc/fstab makes the swap code do one time encryption.
My understanding of that is if you have stuff written to swap, then you shutdown and reboot, you get a different key and the contents of swap is unreadable because the original key is gone.
Perhaps my hypothesis is wrong, just trying to figure out possibilities based on what we've been told.
What we've been told is the user is keeping the workload/pattern the same, the only thing different is ".eli on swap partition or not"
Guess what - tried running the same command at almost full swap. Still nothing :/ (no pids, username,command etc)Thanks. It'll be useful to capture output at a time when a process is identifiable.
So, please re-run the command at an appropriate time.
systat -swap
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |||||||||||||||||||||||||||||||||||
Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ 90\ 100|
ada0p4 7932M 7692M XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Pid Username Command Swap/Total Per-Process Per-System
Still nothing :/
I should not leave it running constantly (in my case, doing so impacts performance; YMMV).
… reasonably detailed statistics while utilizing a minimum amount of CPU time to record them. Thus, no statistical calculations are actually performed in the kernel portion of the devstat code. Instead, that is left for user programs to handle. …