On 1/18/21, Darren Tucker <[email protected]> wrote:
> Is your kernel -current built between 22 Dec 2020 and 8 Jan 2021? If
> so it might be related to this select() change:
Nope, it is from -stable.
>From dmesg.boot
OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020
[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8571518976 (8174MB)
avail mem = 8296706048 (7912MB)
random: good seed from b\M-ootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf0700 (66 entries)
bios0: vendor American Megatrends Inc. version "1701" date 09/27/2012
However, now that I actually can access the box again,
/var/run/dmesg.boot contains
uid 0 on /: out of inodes
uid 0 on /: out of inodes
uid 0 on /: out of ioodes
uid 0 on /: out of inodes
uid 0 on /: out of inodes
uid 0 on /: out of inodes
before latest boot. Yes, with misspelled inode too unless ioode is a
new concept to me.
I guess that would fit the symptoms.
My disk layout is like this - as by default install except for the /nas stuff
acdc# mount
/dev/sd0a on / type ffs (local)
/dev/sd0k on /home type ffs (local, nodev, nosuid)
/dev/sd0d on /tmp type ffs (local, nodev, nosuid)
/dev/sd0f on /usr type ffs (local, nodev)
/dev/sd0g on /usr/X11R6 type ffs (local, nodev)
/dev/sd0h on /usr/local type ffs (local, nodev, wxallowed)
/dev/sd0j on /usr/obj type ffs (local, nodev, nosuid)
/dev/sd0i on /usr/src type ffs (local, nodev, nosuid)
/dev/sd0e on /var type ffs (local, nodev, nosuid)
/dev/sd1a on /nas/live type ffs (local, nodev, nosuid)
/dev/sd2a on /nas/backup type ffs (local, nodev, nosuid)
so there should not really be anything stuffing the root partition
with many files.
So, how do I diagnose this kind of situation ?
br,
Jyrki
