Summary: | swapinfo shows incorrect information for vnconfig'd swap. | ||
---|---|---|---|
Product: | Base System | Reporter: | Jordan Hubbard <jkh> |
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | ||
Priority: | Normal | ||
Version: | 2.1-STABLE | ||
Hardware: | Any | ||
OS: | Any |
Description
Jordan Hubbard
1995-11-30 19:00:01 UTC
>On a system with swap space added via vnconfig, swapinfo prints an >entry like this for the vn0 device: >/dev/?? 65536 0 65472 0% Interleaved >>How-To-Repeat: > dd if=/dev/zero of=/usr/swapfile bs=4k count=16384 > vnconfig /dev/vn1 /usr/swapfile ^0 > swapon /dev/vn1 ^0 This is probably because you don't have /dev/vn0b and/or because you didn't specify swapping on the `b' partition. Unless slicing is enabled, the slice _and_ partition bits in the minor number are ignored, so /dev/vn0 is a bogus alias for /dev/vn0b and swapping on /dev/vn0 may work for bogus reasons. If slicing is enabled, then vnsize() is broken - it returns the full size, not the partition size. Bruce Responsible Changed From-To: freebsd-bugs->dyson John work on swapon/swapoff Responsible Changed From-To: dyson->dg John Dyson has resigned from the FreeBSD project. State Changed From-To: open->analyzed I looked at the PR in some detail and can confirm some of this. The first vn device used will be vn0b, logically. However, when you use more vn devices for swapon, swapinfo will reply with: [17:50] [root@daemon] (26) # swapinfo Device 1K-blocks Used Avail Capacity Type /dev/da0s1b 262016 53440 208576 20% Interleaved /dev/rvn0 65408 0 65408 0% Interleaved /dev/#C43:0x1000a -64 -64 0 100% Interleaved /dev/#C43:0x10012 896 0 896 0% Interleaved Total 328256 53376 274880 16% It shows the device major:minor instead of the device name. The rest works perfectly though. The -64 was a too small dd'd file I created. So the problem as originally reported in the PR doesn't exist anymore in 4.0 and onwards, and I suspect the same to be true for 3.4-R and onwards as well. But I am just curious about the above. Responsible Changed From-To: dg->freebsd-bugs Two years allocated, time to let the freebsd-bugs list at it again so that we can finally resolve this. State Changed From-To: analyzed->closed Has been fixed on -STABLE. -CURRENT no longer uses vnconfig. md does not exhibit this problem. |