Vnode-backed swap space doesn't seem to work at boot. md0 is created but the swap memory is not added to the system and swapon complain that it is already in use. Manually releasing md0 (mdconfig -d -u0) and running swapon -a fix the problem but must be done at every boot. My fstab entry for the swapfile is the following: md none swap sw,file=/var/spool/swap/swapfile 0 0 Fix: More a workaround, once boot do the following as root: # mdconfig -d -u0 # swapon -a How-To-Repeat: 1) Add a swafile via /etc/fstab: md none swap sw,file=/var/spool/swap/swapfile 0 0 2) reboot the system and check if the swapfile is avalable.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Make a random assignment.
Having the same problem. This worked on 10.0-RELEASE. After upgrading to 10.1-RELEASE, it no longer works. /etc/fstab: md99 none swap sw,file=/swap0 0 0 After boot: # mdconfig -lv md99 vnode 256M /swap0 # swapinfo Device 1K-blocks Used Avail Capacity # Deleting the md and calling swapon by hand works. # mdconfig -d -u 99; swapon -a; swapinfo -h swapon: adding /dev/md99 as swap device Device 1K-blocks Used Avail Capacity /dev/md99 262144 0B 256M 0%
If you add "late" to the mount options, it will work. This is not properly documented. With kind regards, Robert Schulze
FYI: See Bug 206048 - 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black) amd64 etc: swapfile usage hangs; swap partition works for a problem that may apply to 10.x as well when using things like: file=/var/spool/swap/swapfile file=/swap0 --unless those files are on their own file systems/partitions not used for other (used) files. (A swap file by itself on its own partition/file system has not shown the problem. Mixing with other IO from the same file system/partition does. But only so much information can be put in a subject line.) It may be worth testing if the involved 10.x context(s) hang before settling on this sort of placement of the file. One of the comments suggested a command like: stress -d 2 -m 3 --vm-keep was sufficient to show the problem on at least 11.0-CURRENT amd64 contexts. I guess that command is from the port sysutils/stress . It would actually be good to have 10.x comments in Bug 206048 reporting how such testing went if someone tries it.
*** Bug 204485 has been marked as a duplicate of this bug. ***