Unlinking files by the process does not free up space

[olegkapitonov]

The problem is mainly occurs when using the Falkon browser.

1. This browser uses RAM FS to store temporary files. When it is running, RAMFS is quickly filled to capacity, it is not released when the browser process is closed. At the same time, there are no files, but the space is occupied.

2. If you unmount RAMFS, then Falcon starts writing the same files to the shared_memory folder on the system BeFS disk, and the same thing happens! The free space on the disk is running out, there are no files, the space is not freed up even when rebooting.

3. The checkfs utility identifies indirect blocks that can be freed and returns space.

Running under strace gives the following sequence of system calls:

​https://pastebin.com/0hZtDp4r

[AlienSoldier]

Got here from this tread: ​https://discuss.haiku-os.org/t/cleaning-system-resources-cache-memory/14401/16

I can attest i get this also from using Falkon. It may also explain other problem with other app but Falkon take the cake to trigger the problem. I experience it on 32 bit, so all flavor seem touched.

When shit hit the fan, i usually have 1 core in proces controler that is trough the roof and it is the kernel "low ressource manager". It continue to act that way even if i quit or kill falkon. Often i will also have only the move that i can move and it will move sporadiclly at that point. Only a computer reset solve that.

I barely can work more than 1 hour before having this happen. Lot of Gmail communication by email seem to cause it faster.

[olegkapitonov]

It seems that the problem is here, in the VFS layer of the kernel ​https://github.com/haiku/haiku/blob/fffd9d7dd4fa068fd0ec7700598248575fe2a692/src/system/kernel/fs/fd.cpp#L217

The reference count of the file descriptor (ref_count) should be equal to 1 here when closing the file, then the descriptor will be freed, and his vnode will be freed (because the file already unlinked by the Falkon). But in fact, ref_count == 2 here, with Falcon (with any other application everything is as it should be - ref_count=1 here). I think that somewhere a reference to this descriptor is created and mistakenly not released.

I added a hack - resetting ref_count to 1 when closing a file, here ​https://github.com/haiku/haiku/blob/fffd9d7dd4fa068fd0ec7700598248575fe2a692/src/system/kernel/fs/fd.cpp#L271

descriptor->ref_count = 1

Now the descriptor and his vnode are correctly released and the space is no more leaking! Falcon works fine, consumes much less memory when working, and completely frees up memory when closed! But this hack doesn't work well - the kernel randomly crashes.

[waddlesplash]

Fixed merged in hrev57501.

A FD/vnode leak was what I'd guessed, but I didn't get around to investigating before X512 did, it seems. Thanks!