Re: uvn_flush: WARNING: changes to page may be lost
On Thu, Nov 12, 2020 at 08:24:51PM +0100, Paul de Weerd wrote: > | > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. > | > > uvn_flush: WARNING: changes to page may be lost! > From the reply Mark sent me on June 9th[1]: > > > What you're seeing is what happens when a program writes to a file by > > using mmap(2) and there is no disk space available when the kernel > > finally decides to write out the modified memory to disk. > > There's plenty of space available in RAM, so you can create a file > that's bigger than the amount of space available on disk. Then > trying to write it to disk will fail with the error you got. Thanks, it makes sense that mmap() would be involved. Since I've only read the books and haven't actually written anything that uses mmap() I was under the impression that you can't use mmap() and friends to extend or create a file; the filesystem needs to have a file at least as big as the area you're mapping. So (just to understand what's going for my own curiosity) what are the ways you can end up in a situation where the kernel wants to write out mmapped data to disk, but there's no space in the filesystem to store that data? My first guess would be mmap()ing a sparse file. My second guess would be something where the file size was changed after the mapping was created, but before the data was written back. Probably a scenario where the msync(2) manpage warns for: "Filesystem operations on a file that is mapped for shared modifications are unpredictable except after an msync()." Thanks for pointing me in this direction, it resulted in an interesting half hour of reading web pages about mmap on several OSes. :) Regards, Jurjen Oskam
Re: uvn_flush: WARNING: changes to page may be lost
On Thu, Nov 12, 2020 at 07:34:41PM +0100, Jurjen Oskam wrote: | On Wed, Nov 11, 2020 at 05:54:36AM -0700, Todd C. Miller wrote: | | > On Wed, 11 Nov 2020 10:20:41 +0100, Jan Stary wrote: | | > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. | > > uvn_flush: WARNING: changes to page may be lost! | | > This happens when /usr/libexec/reorder_kernel runs and your /usr | > is full. If you have upgraded the system multiple times there is | | I ran into this earlier this year, and tried to figure out how a filesystem becoming | full could result in kernel messages such as this. As there are no softupdates | involved, I would have expected the kernel only to return a message about /usr | being 100% full, and the (user space) kernel relinking to simply fail. | | I wasn't able to figure out what was going on. Is the relinking special in some | way? Or is it possible that other situations where a filesystem fills up can | result in messages like this? (Not counting situations where softupdates are | enabled) >From the reply Mark sent me on June 9th[1]: > What you're seeing is what happens when a program writes to a file by > using mmap(2) and there is no disk space available when the kernel > finally decides to write out the modified memory to disk. There's plenty of space available in RAM, so you can create a file that's bigger than the amount of space available on disk. Then trying to write it to disk will fail with the error you got. Cheers, Paul [1]: https://marc.info/?l=openbsd-bugs=159170985316978=2 -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: uvn_flush: WARNING: changes to page may be lost
On Wed, Nov 11, 2020 at 05:54:36AM -0700, Todd C. Miller wrote: > On Wed, 11 Nov 2020 10:20:41 +0100, Jan Stary wrote: > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. > > uvn_flush: WARNING: changes to page may be lost! > This happens when /usr/libexec/reorder_kernel runs and your /usr > is full. If you have upgraded the system multiple times there is I ran into this earlier this year, and tried to figure out how a filesystem becoming full could result in kernel messages such as this. As there are no softupdates involved, I would have expected the kernel only to return a message about /usr being 100% full, and the (user space) kernel relinking to simply fail. I wasn't able to figure out what was going on. Is the relinking special in some way? Or is it possible that other situations where a filesystem fills up can result in messages like this? (Not counting situations where softupdates are enabled) Regards, Jurjen Oskam
Re: uvn_flush: WARNING: changes to page may be lost
On Wed, 11 Nov 2020 10:20:41 +0100, Jan Stary wrote: > This is current/amd64 on an APU2 (dmesg below). > It seems that after every sysupgrade, > there is a storm of messages like these: > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > > They appear right after the booting sequence is finished, > and never appear again. This does not happen after a regular > reboot, only after sysupgrade's reboot. The logs of the last > three occasions follow. This happens when /usr/libexec/reorder_kernel runs and your /usr is full. If you have upgraded the system multiple times there is probably cruft in /usr you can remove such as old shared libraries and obsolete binaries. Your removal of /usr/X11R6 probably is what "fixes" it after sysupgrade. - todd
Re: uvn_flush: WARNING: changes to page may be lost
Hi Jan, On Wed, Nov 11, 2020 at 10:20:41AM +0100, Jan Stary wrote: | uvn_flush: obj=0x0, offset=0x7c2. error during pageout. | uvn_flush: WARNING: changes to page may be lost! | uid 0 on /usr: file system full | Are the uvn and klog errors simply artifacts of the full /usr ? Having experienced this myself, yes, this is /usr being full. Kernel relinking isn't working out. Make sure /usr is bigger to prevent issues like these. https://marc.info/?l=openbsd-bugs=159171382418585=2 If you want to use sysupgrade, you'll have X sets installed every time so increasing /usr's size (or adding a dedicated partition for /usr/X11R6) can help. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
