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@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@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@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@hot52 mnt]# mkdir r1
[root@hot52 mnt]# mount /dev/ram1 r1
[root@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
