On 2020-01-05, Jurjen Oskam <[email protected]> wrote: > On Thu, Oct 31, 2019 at 08:01:25AM -0000, Stuart Henderson wrote: > >> On 2019-10-30, Jurjen Oskam <[email protected]> wrote: >> > >> > All snapshots I tried up to and including this point did not show the >> > problem: >> > OpenBSD 6.6-beta (GENERIC.MP) #202: Mon Aug 12 11:01:21 MDT 2019 >> > >> > All snapshots I tried starting from this point show the problem: >> > OpenBSD 6.6-beta (GENERIC.MP) #207: Tue Aug 13 11:32:34 MDT 2019 >> > >> > >> > Would it be helpful to start a binary search for the exact commit that >> > introduced the problem? >> >> Yes, definitely! We usually do this with date-based cvs updates. >> >> > I've been looking at the commit history around >> > that time but haven't been able to spot an obvious candidate; but that's >> > probably because I'm not a programmer. >> >> Sometimes diffs are tested in snapshots before they're committed, >> so you might need to look beyond the snapshot dates to find the >> commit. > > This took a while. I was not able to isolate a commit, but I did find > the variable that can reliably trigger the problem. > > It's a bit embarrasing to say that the trigger is a f*ckup at my end: in my > template configuration for short-lived VMs, I accidentally configured /usr > to be 1G. I'm aware this is too small, but I never noticed because it > didn't seem to cause any problem for quite a few releases. I guess at > some point the kernel grew a bit and then the problem started to occur > during reorder_kernel. > > After configuring /usr to be created at 4G (and leaving everything else the > same), the problem never occurred again. > > This does lead me to a question though. Is it expected that a (nearly) full > filesystem can result in dmesg error messages such as these? (None of the > filesystems on the system are mounted softdep)
I would not expect to see that from a full filesystem. I think it would be worth sending a write-up (including full dmesg and disklabel) to bugs@ as I would guess that people who might have a better idea what's going on here aren't likely to read misc@ frequently. > uvn_flush: obj=0xfffffd813ee78298, offset=0x33f0000. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x33f0000. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > [ repeat last two lines many times ] > uvn_flush: obj=0xfffffd813ee78298, offset=0x3400000. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x3400000. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > [ repeat last two lines many times ] > > /dev/sd0a on / type ffs (local) > /dev/sd0i 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/sd0e on /var type ffs (local, nodev, nosuid) > > Regards, > > Jurjen Oskam > >
