Date: Sun, 28 Nov 2021 12:53:54 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Chris Ross <cross+freebsd@distal.com>, freebsd-fs <freebsd-fs@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: swap_pager: cannot allocate bio Message-ID: <25012f1b-fb02-1e36-3414-e2696d080999@grosbein.net> In-Reply-To: <09989390-FED9-45A6-A866-4605D3766DFE@distal.com> References: <9FE99EEF-37C5-43D1-AC9D-17F3EDA19606@distal.com> <09989390-FED9-45A6-A866-4605D3766DFE@distal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
11.11.2021 11:43, Chris Ross wrote: >> On Nov 10, 2021, at 23:35, Chris Ross <cross+freebsd@distal.com> wrote: >> >> Hey all. I have a system that I’m trying to do some intensive CPU and I/O on. FreeBSD 13.0-RELEASE, amd64, 128GB RAM, hardware RAID1 OS volume, and a large (40TB) zpool where most of the I/O is happening. >> >> Initially, it was failing for me because it was running out of swap space. It had only the normal small (4-8G) swap partition, so I resized the filesystems on the root disk and now have 400+GB swap. The system had frozen up and I wasn’t able to log in. When I go to the console, I find a long list of: >> >> swap_pager: cannot allocate bio >> >> lines. I was able to log into the console as root and pstat -s shows the swap minimally used (7.5GB used). Attempting a “zpool status” at that point locked up. I don’t know if the problem is the memory subsystem, or zfs. >> >> But, based on the error, is there perhaps some kernel parameter I can tune that might prevent the swap pager from encountering that error? > > Moving to freebsd-fs. More information makes it looks more like a ZFS problem than anything else. > > I am able to log into another root virtual console, and I can run ps (shows many things, including dozens of "cron: running job (cron)” jobs, in D state), and I’m able to wander around the root disk (3T ufs filesystem) without trouble. But, as mentioned above the “zpool status” is hung, and I suspect if I tried to access anything in that filesystem it would hang to. Those cron jobs, which aren’t anything I added, I assume are just system “check around the system” cron jobs that are getting stuck there. > > So, if anyone has any suggestions. I can leave this system stuck like this for a little while, but I’ll probably want to bring it back before the end of the day tomorrow. (I’m US EST, so it’s almost midnight here. I’ll check in on email for suggestions or ideas in the morning.) > > Thanks all. If you have debugging symbols for your kernel and DDB in the kernel, you could drop to DDB with Ctrla-Alt-ESC and try to "call doadump" in the debugger to produce crashdump before reboot for post-mortem analysis. Are you sure you did not enable file-backed swap?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25012f1b-fb02-1e36-3414-e2696d080999>