panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp
spam at rm-rf.kiev.ua
Sun Mar 4 08:47:07 UTC 2007
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
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
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md666a 3561822 3561622 200 100% /tmp/mdtest
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
> > = > 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.
More information about the freebsd-stable