On 28 May 2021 at 02:15p, gcubebuddy pondered and said...
You'll need to identify what is actually writing all the extra data. Rather than "deleting" the file you'll need to truncate it. If you delete an open file the filesystem doesn't actually release the space but a df will show no extra space until reboot. Without any significa data in
the logs I just truncated them nightly.
Spec
Hey! awesome thanks for responding.
by chance, do you know what command you are running to do the
trunication? the only thing that seems to release the space is just rebooting. i have not tried remounting it yet though... so i dont know
if that would help. i did a logout of all accounts associated with /run/user/1000 dir. it also seems that /run is also a seperate mount as well.
Truncating a file like that can be done using the `truncate(2)`
system call. On most Linux distributions, there's a program
called `truncate` that will likely do what you want.
A couple of caveats: the actual details of freeing blocks and
so forth are implemented by the filesystems; it's possible there
exist filesystems where one can `ftruncate()` a file descriptor
or `truncate()` a file with open references and the allocated
block situation doesn't change; I don't know of any that do that,
though. It's a bit of a weird way to approach the world.
The second caveat is that this is likely a good way to create
what we call "sparse" files. Truncating a file that has open
file descriptors against it doesn't modify the offset of that
descriptor in the file. So if you've got a process that has
an open file descriptor for some file, and has been steadily
writing data to it and now has a write offset of, say, a
megabyte then if you truncate it, the allocated blocks associated
with the file will be free, but the next write that process makes
will be at the megabyte offset. The result is a file that appears
to be more than a megabyte long, but the beginning of it will now
all be zeros; most modern OSes won't actually allocate blocks
for those unless you lseek() somewhere in the sparse region and
write something there; reads in that region will be synthetically
filled with zeros. But, again, how that's _actually_ implemented
depends of the filesystem's particular semantics.
I wonder what is causing these files to stick like this and not be
cleared out when the system is done with them... i would imagine that
this should be causing alot of issues for people... i have been trying
to look through my ubuntu 20.04 unleashed book, but can seem to locate anything there. and there doesnt seem to be a lot of info on this issue
or fixes listed in the ubuntu forums. thanks for helping with this.
It's probably a bug. If a file is deleted, but there is still an
open file descriptor that references that file, then the resources
associated with it won't be freed until the last reference to the
file disappears (that is, the last file descriptor referring to it
is close()'d).
You don't have to reboot necessarily, though; if you were to, say,
kill the process holding the file open that should be enough.
Lots of Unix daemons that open log files and things like that will
close() and re-open() them in response to a signal, often SIGHUP
(which, since it's generated by a terminal and daemons are never
supposed to be associated with a terminal, was considered "safe"
to send to a random daemon).
Tools like `lsof` can help you locate what process has what files
open.
--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)