On Thu, Nov 12, 2020 at 08:24:51PM +0100, Paul de Weerd wrote: > | > > uvn_flush: obj=0x0, offset=0x7c20000. 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
