Large Ramdisk creation causes crashes

[Brandon Ooi]

Hi Matt,

I read your I believe it to be a ramdisk limitation because making a 
larger ramdisk, in the exact same manner, gives me a weird error about 
the file system not existing. It's possible that this is a 32bit kernel 
problem that you don't see in x86_64. However, I've experimented with 
x86_64 version of FC3 and we've had trouble with stability in high load 
(random crashes).

Here is an example of the trial.

creating a 512+MB ramdisk fails but the 512MB ramdisk suceeds.

[root at hot52 mnt]# mke2fs -vm0 /dev/ram0 530000
mke2fs 1.37 (21-Mar-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
66400 inodes, 132500 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=138412032
5 block groups
32768 blocks per group, 32768 fragments per group
13280 inodes per group
Superblock backups stored on blocks:
        32768, 98304

Writing inode tables: done                           
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[root at hot52 mnt]# mount /dev/ram0 r0
mount: wrong fs type, bad option, bad superblock on /dev/ram0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

[root at hot52 mnt]# mke2fs -vm0 /dev/ram1 524288
mke2fs 1.37 (21-Mar-2005)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
131072 inodes, 524288 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
64 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Writing inode tables: done                           
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[root at hot52 mnt]# mkdir r1
[root at hot52 mnt]# mount /dev/ram1 r1
[root at hot52 mnt]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             4.0G  1.3G  2.8G  31% /
/dev/sda1              99M  8.8M   85M  10% /boot
/dev/shm              1.5G     0  1.5G   0% /dev/shm
/dev/sda6              63G  2.4G   61G   4% /hot
/dev/sda2             4.0G   35M  3.9G   1% /tmp
/dev/ram1             496M  2.3M  494M   1% /mnt/r1


Brandon



Matt Roth wrote:

>
> Brandon,
>
> I can't specifically comment on your problem because I haven't 
> encountered it, but one thing in your description seemed strange.  I 
> don't believe there is a kernel limit on the size of the RAM disk.  We 
> are running the x86_64 version of FC3 on a machine with 20GB of RAM 
> with a 16GB RAM disk to overcome some I/O bottlenecks we encountered 
> when digitally recording large numbers of VoIP calls.
>
> The details of our setup can be found here:
>
> http://lists.digium.com/pipermail/asterisk-users/2005-October/127919.html
>
> Just search for "RAM Disk Setup" because the document is mainly about 
> NFS optimization and Asterisk.
>
> You seem to be experiencing some strange problems and it's my advice 
> that you start at the beginning (the RAM disk limitation) and work 
> your way forward.
>
> I hope this is helpful to you,
>
> Matthew Roth
> InterMedia Marketing Solutions
> Software Engineer and Systems Developer
>