> 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
