openrc commit 79d6f109 to "improve" swap handling is broken, in two entirely separate ways. From my fstab: ## swap: priority: 0-32767, higher number == higher priority, ## same priority stripes/interleaves LABEL=sw0279gsg0+9bc0 swap swap pri=100 0 0 LABEL=sw0279gsg1+9bc0 swap swap pri=100 0 0 LABEL=sw0279gsg2+9bc0 swap swap pri=100 0 0 LABEL=sw0279gsg3+9bc0 swap swap pri=100 0 0 LABEL=sw0931gio0%---0 swap swap pri=0,noauto 0 0 Problem #1) Given the above fstab, here's the output of /lib64/rc/bin/fstabinfo -b -t swap as used in that commit to get the "device" entries corresponding to the swap-type entries in fstab: LABEL=sw0279gsg0+9bc0 LABEL=sw0279gsg0+9bc0 LABEL=sw0279gsg0+9bc0 LABEL=sw0279gsg0+9bc0 LABEL=sw0279gsg0+9bc0 See the problem? There's five swap entries in my fstab and five lines of output from fstabinfo -b -t swap, but it's the SAME line (the first entry of the five) repeated FIVE times, where clearly, it should be a different line for each of the swap devices listed. That results in only ONE of the five swap devices being actually activated, when it SHOULD be FOUR of them! The other four times I get device busy errors, since it's repeating the same one instead of iterating over all of them. (In case there's any doubt, yes, swapon DOES respond correctly given the correct LABEL= parameter, which is why I get the first one actually activated. I don't have the setup to test it, but I'd assume it does the right thing given UUID= as well. The problem here isn't swapon, and it's not the script, it's fstabinfo!) Problem #2) Even when fed the correct label (as with the first one listed in my fstab, and with the others if I run the swapon command with the label manually), while swapon DOES do the activation, it uses DEFAULT options when doing so, NOT the options from fstab. Thus it sets the first activated swap to -1 priority, the second to -2, etc, instead of setting the configured equal priority for the four. The only way swapon uses the fstab options is when it's fed the -a option, to activate all swap devices listed in fstab. Otherwise it uses defaults unless the options are passed as well. This would be a problem of the script. It's a regression since previously, the script fed swapon -a, so swapon honored the options listed in fstab, including priority and noauto. The priority option is quite important here, since the kernel does round-robin page allocation off all swap devices at the same priority, thereby effectively striping the swap for higher access speed. 4X single spindle speed while way slower than main memory, is STILL 4X faster than single spindle speed! IMO the best and simplest fix here is to simply go back to using swapon -a, but also feed it the -e, aka --ifexists option. According to the swapon manpage, -e/--ifexists silently skips swap devices that aren't available. That would seem to be exactly what we want, combined with -a/--all, so swapon goes thru the full list of swap devices in fstab, honoring the options found there. This would also eliminate having to deal with the fstabinfo duplicate output lines problem above, for this case at least, tho that should certainly be fixed in any case, to prevent similar problems in the future. Duncan
Created attachment 302621 [details] fix-swap.patch This patch would take us back to using swapon -a -e on linux. The reason I switched to activating swap devices individually was so I could skip over the loopback devices until after localmount, so I need to see what happens if we try to mount loopback swap before localmount then go back and pick it up after.
After discussing this with robbat2, we went with your fix. This is fixed in commit e4146c0. Thanks for the report.
