Deleting (recently mounted & unmounted) image file does not free up space

[psycho_killer]

After having mounted and unmounted a BFS image file the space occupied by the file is not freed when the file is deleted.

To reproduce: Take note of the amount of free space on your Haiku volume.
Expand i.e. this file: ​http://haiku-files.org/files/blank-bfs/blank-bfs-512mb.image.zip
then mount it (doubleclick in Tracker), unmount it (through Tracker)
Delete the image file
Observe free space on volume, the 512 MB is not freed, not even after reboot.

System used: R1/alpha (Revision 32945)
On real hardware: 512 MB of memory, 640 MB swap, partition ~2.5 GB

Tested the same file in BeOS R5, space was freed up afterwards.

[scottmc]

Try emptying the trash can. I had this happen to me recently and was trying to figure out why the volume's space bar didn't change when I deleted the image file. Then I deleted all of the files on my scratch partition leaving only the home folder and it still didn't move. Then I realized that the trash sits on the desktop which you can't see in tracker. Emptying the trash I then saw the volume space bar indicators empty out as expected. Try it and let us know if that was the issue.

[psycho_killer]

bfs image file, size 3 MB

[psycho_killer]

iso image file, size 460 KB

[psycho_killer]

Thanks for your confidence in me, scottmc. Ok, jokes aside, thank you for replying. I suspect from your answer that you couldn't reproduce, or what?

I have uploaded two small image files (one bfs and one iso) that behaves like described, not freeing up the space. Should be easier for you all to test with small files. Just have the 'Get info' box open for your volume to note the space before/after deletion.

Space is not freed up whether I delete + empty trash, use shift + Del or use 'rm' in terminal. I booted into BeOS and deleted all the content of the Haiku partition, even did a 'rm -Rf *' in the /haiku root to delete the hidden stuff. Had to reformat to free up the space.

Ok, so I did some more testing.

• Without exception, every time I mount an image file (both bfs and iso) through the gui by double clicking it, I lose that space permanently, also after rebooting. Obviously, this is unfortunate if we're talking about 700 MB iso files.

• Mounting with the terminal can result in either the space being freed or not. In most typical user situations the result is that the space is not released, even after reboot. In fact, the only way I've found to reliably mount an image file and have the space freed up afterwards is as follows: First mount/unmount the file through Tracker, then delete it (and lose the space in the process). Then mount the same file, with the exact same filename, through Terminal using the '-t <file system>' option. (Not specifying file system will result in an error, bug report will follow later.) Now you can unmount the volume (use Terminal) and delete the file, and the space should be regained. It almost seems to be a "bug" that allows this loophole to happen and have the space freed up--it's only the fringe case that behaves correctly.

• It is possible to swap the image file that you use in the second step of the procedure described just above with a different one --as long as it is named exactly the same-- and not loose space occupied by the second file when mounting in terminal. Useful workaround for mounting that big iso.

To sum up, something seems to be up with the mounting of image files, not my trash can handling :-)

[mmlr]

Can you please try the checkfs command on the partition in question? I suppose the file is deleted, but not freed because it is still in use. Then on reboot this gets lost (as our journal format doesn't allow to track this situation). Running checkfs should free up these blocks and show a corresponding block number being freed.

[mmadia]

/dev/disk/virtual/files might be related. after using tracker to unmount and shift-delete the imagefile, this still displays

/dev/disk/virtual/files/20> ls -l
total 1
lrw-r--r-- 1 user root 32 Sep 11 23:19 raw -> /boot/home/Desktop/testbfs.image

[mmadia]

note: checkfs and sync afterwards didnt help.

[psycho_killer]

Yes! checkfs frees up the lost space. But only AFTER you have rebooted, mmdadia. Have a look at the attached screenshots. Thanks for the tip about /dev/disk/virtual -- that was helpful to understand what is going on.

Screenshot 0 is before reboot, checkfs can not do anything and there are several images I have mounted->unmounted->deleted that is listed in the /dev/disk/virtual folder. The others are after the reboot, first just checking (1), then fixing (2), and checking again (3). Note the space left on the volume in the info box down to the right.

I hope this is helpful and that it is possible to fix someday. As I said earlier, the typical user mounting an image will loose the space without knowing how to regain it, both through Tracker and Terminal. As you probably figure out by now the case of space actually being freed up described in my earlier comment (using Terminal after Tracker) is due to that the file in the virtual folder is reused instead of a new one being created.

A little usability side note: Have a look at screenshot checkfs-2.png and notice how the checkfs command says "33011 blocks could be freed" while the haiku info box shows that the space now has been freed. This confused me the first time I ran the procedure, and I discovered later that the space actually had been freed in that step. The solution is obviously to print "could be freed" when using the '-c' option, and print "has been freed" when successfully running the command to fix.

[psycho_killer]

before reboot

[psycho_killer]

after reboot, just checking

[psycho_killer]

fixed, space regained

[psycho_killer]

verify with 'checkfs -c'

[anevilyak]

This one appears to still be with us. By the looks of things the culprit is the virtual / loopback filesystem mount mechanism though, not BFS. Changing component.