kernel panic with memory disks
Stefan Lambrev
stefan.lambrev at moneybookers.com
Tue Aug 21 23:56:07 PDT 2007
Kris Kennaway wrote:
> On Tue, Aug 21, 2007 at 10:32:45AM +0300, Stefan Lambrev wrote:
>
>> Hello,
>>
>> Eric Kjeldergaard wrote:
>>
>>> On 20/08/07, Stefan Lambrev <stefan.lambrev at moneybookers.com> wrote:
>>>
>>>
>>>> Hello,
>>>>
>>>> I do not know if this is know behavior, and I know that 6.2 panic if the
>>>> memory disk got full,
>>>> but on 7-current the panic is before the disk got full.
>>>>
>>>> Here is what I do:
>>>>
>>>> mdconfig -a -t malloc -s 800m
>>>> newfs /dev/md0
>>>> mount /dev/md0 /mnt
>>>> cp 600mb.file /mnt
>>>>
>>>>
>>> -t type
>>> Select the type of the memory disk.
>>>
>>> malloc Storage for this type of memory disk is allocated
>>> with
>>> malloc(9). This limits the size to the malloc bucket
>>> limit in the kernel. If the -o reserve option is not
>>> set, creating and filling a large malloc-backed
>>> memory
>>> disk is a very easy way to panic a system.
>>> -- mdconfig(8)
>>>
>>>
>>>
>> I really should read manuals more carefully :) Thanks for the information.
>>
>> Just one more question - to prevent panic I should use "-o reserve" and
>> have to increase:
>> vfs.maxmallocbufspace
>> vfs.bufmallocspace
>>
>
> No, you should use -o swap. Where did it tell you to change the
> sysctls?
>
> Kris
>
Nowhere just guessing.
I just needed one big file in the memory to ignore the slowness of hard
drives, to run few small benchmarks :)
I did this using tmpfs, but it act just like "-t swap" :)
Btw the confusion comes from the manual of mdconfig where it states:
swap Swap space is used to back this memory disk.
and I thought that type swap is always stored on the hard drives.
and md(4) explains it a lot better:
swap Backing store is allocated from buffer memory. Pages get pushed
out to the swap when the system is under memory pressure,
other-
wise they stay in the operating memory. Using swap backing is
generally preferable over malloc backing.
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
More information about the freebsd-current
mailing list