Large Ramdisk creation causes crashes

[Matt Roth]

 > 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

Brandon,

Notice that the block and fragment sizes for the 512+MB RAM disk are 4KB 
(4096 bytes), but they are 1KB (1024 bytes) for the 512MB one. I believe 
the default RAM disk block size is 1KB, which is why the mount fails for 
the larger RAM disk.

You have two choices to resolve this:

1) Use the "ramdisk_blocksize" kernel parameter to increase the RAM disk 
block size to 4K:
  
   ramdisk_blocksize=4      # I *believe* this size is in KB, but you 
may want to double check
  
2) Use the "-b" parameter to mke2fs to decrease the block size to which 
the RAM disk is formatted to 1K:

   mke2fs -b 1024 -vm0 /dev/ram0 530000
  
Sincerely,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer