2.6.20-rc6 ramdisk problem

2.6.20-rc6 ramdisk problem

[Michal Piotrowski]

Hi,

I want to create a large ramdisk - 1GB

CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024

kernel comman line: ramdisk_size=1000000

$ LANG="c" sudo /sbin/mkfs.ext2 /dev/ram0
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
125184 inodes, 250000 blocks
12500 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=260046848
8 block groups
32768 blocks per group, 32768 fragments per group
15648 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

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.

$ LANG="c" sudo mount /dev/ram0 /mnt/ram0/
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

$ LANG="c" sudo /sbin/tune2fs -l /dev/ram0
tune2fs 1.39 (29-May-2006)
/sbin/tune2fs: Bad magic number in super-block while trying to open /dev/ram0
Couldn't find valid filesystem superblock.

dmesg
EXT2-fs: Magic mismatch, very weird !
VFS: Can't find an ext2 filesystem on dev ram0.

With ramdisk_size=500000 everything is ok.

machine
CPU P4 (ia32)
2 GB RAM

Is this is a hardware (arch) or software limitation? Maybe a bug?

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.20-rc6 ramdisk problem

[Robert Hancock]

Michal Piotrowski wrote:
> Hi,
> 
> I want to create a large ramdisk - 1GB
> 
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=1
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
> 
> kernel comman line: ramdisk_size=1000000
> 
..

> 
> With ramdisk_size=500000 everything is ok.
> 
> machine
> CPU P4 (ia32)
> 2 GB RAM
> 
> Is this is a hardware (arch) or software limitation? Maybe a bug?
> 
> Regards,
> Michal

I'm not sure if there's an inherent max ramdisk size limit, however I 
should point out that in most cases, using a tmpfs or ramfs file system 
is better than old-style ramdisks. Those filesystems return unused 
memory to the kernel (ramdisks statically allocate the entire space) and 
also avoid the filesystem overhead of ramdisks (the files are mapped 
into pagecache directly).

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: 2.6.20-rc6 ramdisk problem

[Thomas Gleixner]

On Wed, 2007-01-31 at 17:54 -0600, Robert Hancock wrote:
> I'm not sure if there's an inherent max ramdisk size limit, however I 
> should point out that in most cases, using a tmpfs or ramfs file system 
> is better than old-style ramdisks. Those filesystems return unused 
> memory to the kernel (ramdisks statically allocate the entire space) and 
> also avoid the filesystem overhead of ramdisks (the files are mapped 
> into pagecache directly).

This is not a question of what's better or not. 

Michal stepped into a real life problem:

1. ramdisk gets created in the first place w/o problems
2. formatting the same ramdisk succeeds
3. trying to use it fails

So either #1 or #2 should have failed in the first place. Failing in #3
is definitely a BUG in #1 or #2.

How does your advise help to fix that BUG ? Ignoring it by using
something else ?

	tglx

Re: 2.6.20-rc6 ramdisk problem

[Robert Hancock]

Thomas Gleixner wrote:
> On Wed, 2007-01-31 at 17:54 -0600, Robert Hancock wrote:
>> I'm not sure if there's an inherent max ramdisk size limit, however I 
>> should point out that in most cases, using a tmpfs or ramfs file system 
>> is better than old-style ramdisks. Those filesystems return unused 
>> memory to the kernel (ramdisks statically allocate the entire space) and 
>> also avoid the filesystem overhead of ramdisks (the files are mapped 
>> into pagecache directly).
> 
> This is not a question of what's better or not. 
> 
> Michal stepped into a real life problem:
> 
> 1. ramdisk gets created in the first place w/o problems
> 2. formatting the same ramdisk succeeds
> 3. trying to use it fails
> 
> So either #1 or #2 should have failed in the first place. Failing in #3
> is definitely a BUG in #1 or #2.
> 
> How does your advise help to fix that BUG ? Ignoring it by using
> something else ?

Yes, there is likely a bug here of some sort. However, that doesn't 
change the fact that ramdisks are sub-optimal for most uses.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: 2.6.20-rc6 ramdisk problem

[Thomas Gleixner]

On Wed, 2007-01-31 at 18:14 -0600, Robert Hancock wrote:
> > So either #1 or #2 should have failed in the first place. Failing in #3
> > is definitely a BUG in #1 or #2.
> > 
> > How does your advise help to fix that BUG ? Ignoring it by using
> > something else ?
> 
> Yes, there is likely a bug here of some sort. However, that doesn't 
> change the fact that ramdisks are sub-optimal for most uses.

You still did not answer my question: 
How does this deep insight help us to track down that BUG ?

Michal is actively testing the kernel and provides extremly useful
information about problems. He pointed out a bug and we want to fix it.
Adding special instructions, which are appropriate for a LUG
mailinglist, does us not get any further.

	tglx