On Tue, Aug 03, 2021 at 12:39:54PM -0700, Greg Thomas wrote:
> I'm definitely suffering from filesystem corruption on root. I had
> rebooted last night with no change.
>
> I have no options for mounting root.
>
> grits# cat /etc/fstab
> 16a27b4b4549ce04.b none swap sw
> 16a27b4b4549ce04.a / ffs rw 1 1
> 16a27b4b4549ce04.k /home ffs rw,nodev,nosuid 1 2
> 16a27b4b4549ce04.d /tmp ffs rw,nodev,nosuid 1 2
> 16a27b4b4549ce04.f /usr ffs rw,nodev 1 2
> 16a27b4b4549ce04.g /usr/X11R6 ffs rw,nodev 1 2
> 16a27b4b4549ce04.h /usr/local ffs rw,wxallowed,nodev 1 2
> 16a27b4b4549ce04.j /usr/obj ffs rw,nodev,nosuid 1 2
> 16a27b4b4549ce04.i /usr/src ffs rw,nodev,nosuid 1 2
> 16a27b4b4549ce04.e /var ffs rw,nodev,nosuid 1 2
> /dev/sd1c /backup ffs rw,nodev,nosuid 1 2
>
> I need to upgrade so I can do that from scratch. This is my backup server
> so the configuration is pretty simple.
>
> Not sure fsck output helps here?
>
> grits# fsck /dev/sd0a
> ** /dev/rsd0a (NO WRITE)
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 12852 files, 469195 used, 35516 free (44 frags, 4434 blocks, 0.0%
> fragmentation)
>
> Anyway, I'll reinstall unless someone has more learning experiences for me.
>
> And thank you to Paul for giving a quick explanation of the difference
> between df and du.
>
> Thanks all!
fsck looks normal for a mounted filesystem.
but did you try following Paul's advice to find an open file that has
no directory entry? That is not corruption, but explains why more
storage is in use than du shows.
-Otto
>
>
>
> On Tue, Aug 3, 2021 at 11:39 AM Ali Farzanrad <ali_farzan...@riseup.net>
> wrote:
>
> > I also suspected that it is a filesystem corruption.
> > Do you have `async` mount option on your root?
> >
> > Sebastien Marie <sema...@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
> > >
> > >
> >
> >
