Were you really performing a ktrac of pflogd? Bryan Stenson <[email protected]> wrote:
> ok...found the panic call here: sys/ufs/ufs/ufs_quota.c:451. From the > comment in the code: "On filesystems with quotas enabled, it is an > error for a file to change size and not to have a dquot structure > associated with it." > > I do have quotas enabled on /home, but limits are only set for a > single user (no groups). Otherwise, I don't think I'm doing anything > crazy/out-of-the-ordinary. Clearly, the kernel got here, but I'm not > sure how. > > sv01$ doas repquota /home > KByte limits File limits > User used soft hard grace used soft hard grace > root -- 398434 0 0 15 0 0 > _syspatch -- 6032 0 0 1 0 0 > stensonb -- 40656 0 0 1755 0 0 > pic-uploader-- 864764 10000000 15000000 305 10000 15000 > sv01$ > > sv01$ cat /etc/fstab > f10723e9888c49b1.b none swap sw > f10723e9888c49b1.a / ffs rw 1 1 > f10723e9888c49b1.k /home ffs rw,nodev,nosuid,noatime,softdep,userquota 1 2 > f10723e9888c49b1.d /tmp ffs rw,nodev,nosuid,noatime,softdep 1 2 > f10723e9888c49b1.f /usr ffs rw,nodev,noatime,softdep 1 2 > f10723e9888c49b1.g /usr/X11R6 ffs rw,nodev,noatime,softdep 1 2 > f10723e9888c49b1.h /usr/local ffs rw,wxallowed,nodev,noatime,softdep 1 2 > f10723e9888c49b1.j /usr/obj ffs rw,nodev,nosuid,noatime,softdep 1 2 > f10723e9888c49b1.i /usr/src ffs rw,nodev,nosuid,noatime,softdep 1 2 > f10723e9888c49b1.e /var ffs rw,nodev,nosuid,noatime,softdep 1 2 > sv01$ > > > On Tue, Mar 31, 2020 at 6:12 AM Bryan Stenson <[email protected]> wrote: > > > > Agreed...I'm not convinced it was due to being hosted on VMM...just > > wanted to include that as a data point (perhaps that detail is > > stressed too much here). > > > > I'm looking/learning about the "missing dquot" panic message now > > (brushing up on CVS, etc). :) > > > > After reboot, the filesystem fsck'd, and all seems to be well at this point. > > > > On Tue, Mar 31, 2020 at 6:09 AM Pratik Vyas <[email protected]> wrote: > > > > > > * Bryan Stenson <[email protected]> [2020-03-31 05:57:46 +0000]: > > > > > > >>Synopsis: panic on vm hosted with VMM - missing dquot > > > >>Category: unknown > > > >>Environment: > > > > System : OpenBSD 6.6 > > > > Details : OpenBSD 6.6-current (GENERIC) #85: Sun Mar 29 > > > >10:50:36 MDT 2020 > > > > > > > >[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC > > > > > > > > Architecture: OpenBSD.amd64 > > > > Machine : amd64 > > > >>Description: I noticed my VM was unresponsive, and upon accessing via > > > >>console, received the ddb prompt. > > > > > > > >>How-To-Repeat: unknown > > > > > > > >>Fix: unknown > > > > > > > >server9$ vmctl console 16 > > > >Connected to /dev/ttypg (speed 115200) > > > >https://www.openbsd.org/ddb.html describes the minimum info required in > > > >bug > > > >reports. Insufficient info makes it difficult to find and fix bugs. > > > >ddb> trace > > > >db_enter() at db_enter+0x10 > > > >panic(ffffffff81c52ce1) at panic+0x128 > > > >chkdquot(fffffd80363fa968) at chkdquot+0xac > > > >ufs_quota_alloc_blocks2(fffffd80363fa968,20,fffffd801b174918,0) at > > > >ufs_quota_al > > > >loc_blocks2+0x2f > > > >ffs_alloc(fffffd80363fa968,23,230648,4000,fffffd801b174918,ffff8000149cd458) > > > > at > > > > ffs_alloc+0x11e > > > >ffs1_balloc(fffffd80363fa968,8c000,50,fffffd801b174918,1,ffff8000149cd550) > > > > at f > > > >fs1_balloc+0xc46 > > > >ffs_write(ffff8000149cd5c0) at ffs_write+0x262 > > > >VOP_WRITE(fffffd803aff95c0,ffff8000149cd650,3,fffffd801b174918) at > > > >VOP_WRITE+0x > > > >4f > > > >ktrwriteraw(ffff8000149ce4f0,fffffd803aff95c0,fffffd801b174918,ffff8000149cd710 > > > >,ffff8000149cd6f0) at ktrwriteraw+0xf3 > > > >ktrsyscall(ffff8000149ce4f0,3,18,ffff8000149cd7d0) at ktrsyscall+0x20c > > > >syscall(ffff8000149cd8a0) at syscall+0x1e8 > > > >Xsyscall() at Xsyscall+0x128 > > > >end of kernel > > > >end trace frame: 0x7f7ffffd6300, count: -12 > > > >ddb> > > > > > > > > > > not sure if this is vmm (unless it's due to disk corruption?). Anything > > > else wrong after reboot? > > > > > > > > > -- > > > Pratik >
