Solved Missing disk space after swap file problems

D

Dylan Allbee

OS: FreeBSD 10.1-RELEASE

I was following the instructions for creating a swap file in the handbook and upon restarting my system top was no longer reporting the swap space as being available. Being the silly, silly novice that I am, I tried recreating /usr/swap0.
Code: 
# dd if=/dev/zero of=/usr/swap0 bs=1m count=4096
# swapon -aq
Still nothing. So now I thought: "Okay let's delete and restart the process".
Code: 
# rm -f /usr/swap0
# dd if=/dev/zero of=/usr/swap0 bs=1m count=4096
# swapon -a
At this point I looked up the man page for swapon(8) and noticed that -q was suppressing possible warning messages. Removing -q produced something somewhat terrifying: The device was already in use. Of course this means that I had likely deleted it while it was actively being used as swap.
Code: 
# df -h
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/vtbd0p2     39G     20G     16G    56%    /

# du -sh /
15.8G    /
I then found this Thread freebsd-10-wont-add-swap-file.47167 explaining that I needed to add "late" to my entry in /etc/fstab. Swap is now working properly!

How can I reclaim the lost disk space? I've restarted the system several times, tried checking inodes, and ran fsck() with no success.
 
The difference might be not related to the swap file topic.
Please see https://www.freebsd.org/doc/faq/disks.html#idp59581264
Code: 
A portion of each UFS partition (8%, by default) is reserved for use by the operating system and the root user. 
df(1) does not count that space when calculating the Capacity column, so it can exceed 100%. 
Notice that the Blocks column is always greater than the sum of the Used and Avail columns, 
usually by a factor of 8%.
 
Well, I'd agree with you, if this wasn't reproducible.

Code: 
# rm -f /usr/swap0
# df -h
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/vtbd0p2     39G     20G     16G    56%    /

# swapoff -a
swapoff: md98 on /usr/swap0: Device not found

# shutdown -r now
# dd if=/dev/zero of=/usr/swap0 bs=1m count=4096
# df -h
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/vtbd0p2     39G     24G     12G    67%    /
 
May be I have not got the point, but from my understanding the command
dd if=/dev/zero of=/usr/swap0 bs=1m count=4096
should make the difference between 20G used and 24G used.The command just creates a file /usr/swap0 of 4096x1m. It makes no difference if it is used as a swap file or not.
 
Yeah perhaps I'm not being clear enough.

Repeating the process in my previous post is continuously reducing my available space by 4 gigs. Notice the process: Create a 4 gig file, swapon(), remove the file, restart the system. The space that /dev/swap0 once occupied does not become available.
 
Ok, now it is clear. I have tried the procedure using a swap file on a spare disk at the partition /dev/gpt/gpt_reserve. I can confirm your observation.
Please run fsk /whereever/usr/is/mounted. I think the disk should be not mounted at all.
The file system check will complain about errors. See the procedure for my test case below.
Code: 
# fsck /dev/gpt/gpt_reserve
** /dev/gpt/gpt_reserve
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] y

SUMMARY INFORMATION BAD
SALVAGE? [yn] y

BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] y
Now I have the full disk back again.
May be this helps in your situation as well.
 
Thanks! I'll be checking this out momentarily and updating with my result.

Update: Well, I'm having trouble running fsck() properly. /usr is on my root filesystem, and so I don't have a way to unmount it that I know of. I tried booting into single user mode and mounting as read only, but then of course fsck() can't fix anything. Do I have any other options?
 
Bam. That did it! You guys are fantastic, and I can't thank you enough. I'll do my best to pay it forward!

Also, is any of this something I should report as a bug?
 
It is good to know that the issue is fixed. I would not consider the behaviour as a bug. Deleting a file to which some other process is writing to should not be the normal use case.
 
You must log in or register to reply here.
Back
Top