Re: Can't figure out what's taking up space on /

I also suspected that it is a filesystem corruption.
Do you have `async` mount option on your root?

Sebastien Marie <semarie@online.fr> wrote:
> On Tue, Aug 03, 2021 at 10:03:44AM +0200, Paul de Weerd wrote:
> > df shows you how much data you can write to an fs, while du shows the
> > disk usage of files it can find. If it can't find a file (because
> > it's been deleted), it won't account for it. But if it's been deleted
> > and still held open by some process, it would still consume disk
> > space.
> >
> > So it looks like a process has a file open on the root filesystem that
> > has been deleted. You're looking for a root-owned process that is
> > (probably) long-running. My guess the file is in /dev/ (that's my
> > crystal ball talking though).
> >
> > Easiest way out is generally to reboot - this stops all processes
> > (d0h), dus freeing up all the resources they had tied up, including
> > files that had been deleted from the filesystem. But going through
> > your process list to see if you can spot something that may have done
> > this can be a good learning experience. In general, base OpenBSD
> > daemons don't behave this way.
>
> I agree with Paul: you should have a running process which hold
> descriptor on unlinked file.
>
> fstat(1) could be used to see list of opened files, and specially
> unlinked files:
>
> INUM The inode number of the file. It will be followed by an asterisk
> ('*') if the inode is unlinked from disk.
>
>
> $ fstat | grep -F '* -'
> [...]
> semarie chrome 537 25 /tmp 48* -rw------- rwp 279793
> [...]
>
> here, chrome (pid 537) has descriptor 25 opened to a file on /tmp
> inode=48 (unlinked), the file size is 279793 bytes.
>
> --
> Sebastien Marie
>
>