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/)
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 [email protected]
Home Page: http://www.roberthancock.com/
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
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 [email protected]
Home Page: http://www.roberthancock.com/
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