Re: tmpfs weirdness
On Tue, Apr 22, 2014 at 05:11:35PM -0500, Shawn K. Quinn wrote: Also, it should be noted tmpfs allocates the entire amount of memory available by default. Nope. Your wording is incorrect. mfs *reserves* memory. tmpfs doesn't. If you want to put limits on it, you can use parameters to mount to make sure you limit the memory used. Otherwise, it is unlimited, and interacts with uvm. Note that the rest of the system is unlimited by default either. If you run enough processes that allocate memory, you will run uvm out of memory as well...
Re: tmpfs weirdness
On Tue, Apr 22, 2014, at 11:24 PM, Chris Cappuccio wrote: there are some interesting patches in bitrig that you could try to apply in the openbsd tree, recompile your kernel and see if any of them help. https://github.com/bitrig/bitrig/commit/c2ce175 Fix integer overflows handling objects = 2G Fix a series of overflows preventing objects larger than two gigabytes from being handled correctly by uvm_aobj.c. Since kernel_object_store is 4G on amd64, this is slightly worrying. I started with this one, and I cannot get it to apply cleanly. It looks like whatever is in -current now has diverged enough from what Bitrig took or vice versa to make applying it by hand tricky at best. Given my horrible luck with this one, I am hesitant to try the others. -- Shawn K. Quinn skqu...@rushpost.com
Re: tmpfs weirdness
On Wed, Apr 23, 2014 at 9:06 AM, Marc Espie es...@nerim.net wrote: On Tue, Apr 22, 2014 at 05:11:35PM -0500, Shawn K. Quinn wrote: Also, it should be noted tmpfs allocates the entire amount of memory available by default. Nope. Your wording is incorrect. mfs *reserves* memory. tmpfs doesn't. If you want to put limits on it, you can use parameters to mount to make sure you limit the memory used. Otherwise, it is unlimited, and interacts with uvm. Note that the rest of the system is unlimited by default either. If you run enough processes that allocate memory, you will run uvm out of memory as well... Running out of memory for uvm and having just message about it on console or in log is boring. We need to implement Oom-killer. That's real fun for real men. Killing randomly processes to free up RAM. Including stuff like init after that everything is free :D
Re: tmpfs weirdness
On Wed, Apr 23, 2014 at 03:30:51AM -0500, Shawn K. Quinn wrote: On Tue, Apr 22, 2014, at 11:24 PM, Chris Cappuccio wrote: there are some interesting patches in bitrig that you could try to apply in the openbsd tree, recompile your kernel and see if any of them help. https://github.com/bitrig/bitrig/commit/c2ce175 Fix integer overflows handling objects = 2G Fix a series of overflows preventing objects larger than two gigabytes from being handled correctly by uvm_aobj.c. Since kernel_object_store is 4G on amd64, this is slightly worrying. I started with this one, and I cannot get it to apply cleanly. It looks like whatever is in -current now has diverged enough from what Bitrig took or vice versa to make applying it by hand tricky at best. Given my horrible luck with this one, I am hesitant to try the others. Yes, filesystem is an area where things can be very deadly... which is one reason why we haven't caught up with what Pedro did in undeadly yet. It is on my list of things to look at whenever I have a bit of time...
Re: tmpfs weirdness
On Mon, Apr 21, 2014, at 12:26 AM, Shawn K. Quinn wrote: With a tmpfs mounted on /tmp: $ cd /tmp $ dd if=/dev/zero of=0 bs=1M ; sync ; sleep 5 ; rm 0 results in dmesg getting spammed with: uao_flush: strange, got an out of range flush (fixed) Forgot to mention, this is on amd64 with a recent snapshot. If the tmpfs is large enough (larger than physical RAM, maybe?) another error happens (I don't have it handy right now) That error would be: pagedaemon: wait_pla deadlock detected! Screenshots of ddb info available temporarily at: http://www.shawnkquinn.com/openbsd-tmpfs-crash/ (Some may be duplicates, a couple may have a small part of the screen cut off. Enough should be legible to figure out what's going on.) and the system usually winds up wedged badly enough that boot dump from ddb won't work as designed. I can reproduce this on request. Also, it should be noted tmpfs allocates the entire amount of memory available by default. When I do something similar with mfs, I can write at least an 8G file to a 10G mfs disk, and the system does not actually crash. It does slow down and the load average skyrockets (8.25 right after killing dd) but the system never becomes unusable. -- Shawn K. Quinn skqu...@rushpost.com
