Re: 1Gb ramdisk in RHEL3
Michael ODonnell writes: > > > OK, the ramdisk story is looking a bit better now. > > First, the tmpfs trick is definitely cool and worth remembering > but isn't what we're looking for because some of what makes it > cool also makes it unsuitable for our purposes. In particular, > tmpfs has close ties to the kernel's buffer cache so files > in tmpfs may actually be on backing store and since we're > investigating a ramdisk solution to get some low-latency > characteristics that makes tmpfs unsuitable for our purpose. > Too bad, because rigging tmpfs is easier than rigging a ramdisk. > > The key to getting the [EMAIL PROTECTED]@!!! ramdisk to be usable was > figuring > out that ext2 and the ramdisk device driver had to agree on > block size. The default for ramdisk is 1k and the default for > ext2 is 4k. At first I tried to specify ramdisk_size=1048576 > and ramdisk_blocksize=4096 on the kernel commandline (units are > Kb for the former and bytes for the latter) and all would have > been well. except that the machine in question boots from an > initrd and the ext2 filesystem therein was already specified as > using 1k blocks and the kernel panic'd when it failed to mount > the initrd due to that mismatch. > > So, since I don't feel like rebuilding the initrd's filesystem > with 4k blocksize I had the ramdisk fall back to the default 1k > and told mkfs.ext2 to build the filesystem in the ramdisk using > a 1k blocksize, thus: > >dd if=/dev/zero bs=1024k count=1048576 of=/dev/ram9 >mkfs.ext2 -b 1024 /dev/ram9 >mount /dev/ram9 /mnt/test If you're using a ramdisk for purposes other than booting, make sure you have backported this fix if you are running a kernel older than 2.6.24: if you don't, your ramdisk blocks will disapear once you use all the ram in the system and the kernel needs to free memory http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5d0360ee96a5ef953dbea45873c2a8c87e77d59b -- Dave ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: 1Gb ramdisk in RHEL3
OK, the ramdisk story is looking a bit better now. First, the tmpfs trick is definitely cool and worth remembering but isn't what we're looking for because some of what makes it cool also makes it unsuitable for our purposes. In particular, tmpfs has close ties to the kernel's buffer cache so files in tmpfs may actually be on backing store and since we're investigating a ramdisk solution to get some low-latency characteristics that makes tmpfs unsuitable for our purpose. Too bad, because rigging tmpfs is easier than rigging a ramdisk. The key to getting the [EMAIL PROTECTED]@!!! ramdisk to be usable was figuring out that ext2 and the ramdisk device driver had to agree on block size. The default for ramdisk is 1k and the default for ext2 is 4k. At first I tried to specify ramdisk_size=1048576 and ramdisk_blocksize=4096 on the kernel commandline (units are Kb for the former and bytes for the latter) and all would have been well. except that the machine in question boots from an initrd and the ext2 filesystem therein was already specified as using 1k blocks and the kernel panic'd when it failed to mount the initrd due to that mismatch. So, since I don't feel like rebuilding the initrd's filesystem with 4k blocksize I had the ramdisk fall back to the default 1k and told mkfs.ext2 to build the filesystem in the ramdisk using a 1k blocksize, thus: dd if=/dev/zero bs=1024k count=1048576 of=/dev/ram9 mkfs.ext2 -b 1024 /dev/ram9 mount /dev/ram9 /mnt/test ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: 1Gb ramdisk in RHEL3
Hmmm. This command apparently has the desired effect: mount -t tmpfs none /mnt/test -o size=1073741824 ...though I don't claim to understand what's going on behind the scenes. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
1Gb ramdisk in RHEL3
I'm trying to persuade an RHEL3.9 PAE kernel running on a machine
with 4GB RAM to let me create a ~1Gb ramdisk and the results
are, um, vexatious.
I start the kernel with the requisite ramdisk_size=nKb where I've
tried various values of n like 100 and 1048576. After the
kernel boots I say:
dd if=/dev/zero of=/dev/ram1 bs=1k count=n
...and dd reports success writing to the device. I then say:
mkfs.ext2 /dev/ram1
...followed by:
fsck.ext2 -f /dev/ram1
...and I see this:
e2fsck 1.32 (09-Nov-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/ram1: 11/131072 files (0.0% non-contiguous), 4127/262144 blocks
...and everybody appears to be happy. If I generate a hexdump
of the device I see the expected sort of glop:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 - etc...
0400 00 00 02 00 00 00 04 00 33 33 00 00 E1 EF 03 00
33..
0410 F5 FF 01 00 00 00 00 00 02 00 00 00 02 00 00 00
0420 00 80 00 00 00 80 00 00 00 40 00 00 00 00 00 00 [EMAIL
PROTECTED]
0430 AC 49 8A 48 00 00 20 00 53 EF 01 00 01 00 00 00 .I.H..
.S...
0440 AC 49 8A 48 00 4E ED 00 00 00 00 00 01 00 00 00
.I.H.N..
0450 00 00 00 00 0B 00 00 00 80 00 00 00 00 00 00 00
0460 02 00 00 00 01 00 00 00 BC 85 6E EC 56 B1 46 65
..n.V.Fe
0470 95 AA CA CB 96 52 24 C7 00 00 00 00 00 00 00 00
.R$.
0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0490 - etc...
04e0 00 00 00 00 00 00 00 00 00 00 00 00 AE 55 AB 2B
.U.+
04f0 F2 6D 49 80 90 BE 4A BC 8B 3D 5F C4 02 00 00 00
.mI...J..=_.
0500 00 00 00 00 00 00 00 00 AC 49 8A 48 00 00 00 00
.I.H
0510 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0520 - etc...
1000 02 00 00 00 03 00 00 00 04 00 00 00 F7 7D F5 3F
.}.?
1010 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1020 02 80 00 00 03 80 00 00 04 80 00 00 FC 7D 00 40
.}.@
1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1040 00 00 01 00 01 00 01 00 02 00 01 00 FE 7D 00 40
.}.@
1050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1060 02 80 01 00 03 80 01 00 04 80 01 00 FC 7D 00 40
.}.@
1070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1080 00 00 02 00 01 00 02 00 02 00 02 00 FE 7D 00 40
.}.@
1090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10a0 02 80 02 00 03 80 02 00 04 80 02 00 FC 7D 00 40
.}.@
10b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
.
.
.
...but when I then say:
mount /dev/ram1 /mnt/test
...I immediately see this:
mount: wrong fs type, bad option, bad superblock on /dev/ram1,
or too many mounted file systems
...whereupon the same fsck command now says this:
e2fsck 1.32 (09-Nov-2002)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/ram1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
...and the hexdump now shows this:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
