| From | Sent On | Attachments |
|---|---|---|
| Mikhail Teterin | Feb 27, 2007 3:58 pm | |
| Alex Kozlov | Feb 27, 2007 5:05 pm | |
| Mikhail Teterin | Feb 27, 2007 7:47 pm | |
| Alex Kozlov | Feb 27, 2007 8:54 pm | |
| Mikhail Teterin | Feb 27, 2007 9:03 pm | |
| Kris Kennaway | Feb 27, 2007 9:09 pm | |
| Mikhail Teterin | Feb 27, 2007 9:24 pm | |
| Kris Kennaway | Feb 27, 2007 9:28 pm | |
| Kris Kennaway | Feb 27, 2007 9:51 pm | |
| Michael Proto | Feb 27, 2007 10:20 pm | |
| Michael Proto | Feb 27, 2007 10:20 pm | |
| Yar Tikhiy | Mar 4, 2007 8:27 am | |
| Alex Kozlov | Mar 4, 2007 8:46 am | |
| Kris Kennaway | Mar 5, 2007 3:59 am | |
| Yar Tikhiy | Mar 5, 2007 1:24 pm | |
| Mikhail Teterin | Mar 5, 2007 6:40 pm | |
| Yar Tikhiy | Mar 5, 2007 7:17 pm | |
| Kostik Belousov | Mar 5, 2007 8:00 pm | |
| Yar Tikhiy | Mar 5, 2007 8:13 pm | |
| Scott Long | Mar 5, 2007 9:13 pm | |
| Artem Kuchin | Mar 5, 2007 9:43 pm | |
| Jack Vogel | Mar 5, 2007 10:21 pm | |
| Steven Hartland | Mar 5, 2007 10:26 pm | |
| Jeremy Chadwick | Mar 6, 2007 12:07 am | |
| Charles Sprickman | Mar 6, 2007 3:14 am | |
| Artem Kuchin | Mar 6, 2007 8:47 am | |
| Tom Judge | Mar 6, 2007 10:09 am | |
| Artem Kuchin | Mar 6, 2007 10:53 am | |
| Tom Judge | Mar 6, 2007 11:08 am | |
| Artem Kuchin | Mar 6, 2007 11:24 am | |
| Yar Tikhiy | Mar 6, 2007 1:16 pm | |
| Artem Kuchin | Mar 6, 2007 1:25 pm | |
| Jack Vogel | Mar 6, 2007 6:04 pm | |
| Vivek Khera | Mar 6, 2007 8:16 pm | |
| Jack Vogel | Mar 6, 2007 9:09 pm | |
| Torfinn Ingolfsen | Mar 7, 2007 12:16 am | |
| Danny Braniss | Mar 7, 2007 7:36 am | |
| Jeremy Chadwick | Mar 7, 2007 9:24 am | |
| Jan Mikkelsen | Mar 7, 2007 12:51 pm | |
| ian j hart | Mar 7, 2007 9:40 pm | |
| Jeremy Chadwick | Mar 7, 2007 10:05 pm | |
| ian j hart | Mar 7, 2007 10:50 pm | |
| Parv | Mar 12, 2007 10:25 pm |
| Subject: | panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up | |
|---|---|---|
| From: | Alex Kozlov (sp...@rm-rf.kiev.ua) | |
| Date: | Mar 4, 2007 8:46:49 am | |
| List: | org.freebsd.freebsd-stable | |
On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote:
On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:
On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: = > Yes, I switched to swap-backed md already. But the malloc-based variety is = > currently the _default_ (see /etc/defaults/rc.conf)... = Bad default.
Filing a PR.
Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. OTOH, if we add '-o reserve', that will break systems with a too large but mostly unused tmpmfs. A sort of a loud announcement will be needed.
#sudo swapoff /dev/ad4s2b #swapinfo Device 1K-blocks Used Avail Capacity
#mdconfig -d -u 666 && \ mdconfig -a -t swap -s10000M -u 666 && \ bsdlabel -w /dev/md666 auto && \ newfs -U -f 512 -b 4096 -i 512 -m 0 /dev/md666a && \ mkdir /tmp/mdtest && \ mount /dev/md666a /tmp/mdtest $dd if=/dev/zero of=/tmp/mdtest
#df /tmp/mdtest Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md666a 3561822 3561622 200 100% /tmp/mdtest #dmesg Mar 4 10:20:35 ravenloft kernel: pid 97529 (firefox-bin), uid 1001, was killed: out of swap space Mar 4 10:20:39 ravenloft kernel: pid 79658 (Xorg), uid 0, was killed: out of swap space Mar 4 10:20:40 ravenloft kernel: pid 519 (thunderbird-bin), uid 1001, was killed: out of swap space
Ouch, but this is still better than panic.
By the way, I seem to be the one responsible for the paragraph in rc.conf(5) advocating -M "for maximum performance and system stability at low memory conditions". When I wrote it, I thought as follows: were the system low on memory, additional swap activity due to mfs would just make the system start thrashing sooner, while malloc'd mfs would just report ENOSPC. I was unaware of the panic back then. Perhaps it was a misconception, either. I haven't heard of any real pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no good.
= > Creation of a 2Gb malloc-based md should've failed on a machine with = > 768Mb of RAM, shouldn't it have? = Only if you set '-o reserve'. Memory for malloc-based md was allocated = dynamically.
But malloc can only allocate from RAM, right? So the amount of RAM is the hard limit, which a malloc-based md can not exceed even in theory. This means, md-creation should've failed...
In fact, the limit should, of course, be even lower -- and mdmfs should be smart enough to substract the sizes of other kernel memory chunks from the maximum.
Since even that would still not be a guarantee against running out, the system should be able to recover gracefully instead of panicing. Do you agree?
FWIW, some discussion of the panic is in the audit trail of kern/87255. Irrespective of tmpmfs defaults, this is a way to panic the system with stock tools and without doing something totally stupid like writing junk to /dev/mem.
-- Adios





