Re: Large Ramdisk creation causes crashes

[Matt Roth <mroth@xxxxxxxxxx>]

> 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

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