Re: Ramdisk Bug?

From: Zeng Yu (yu_zeng@263.net)
Date: Thu Jun 28 2001 - 09:21:15 EST


> > I think find a ramdisk bug of 2.4.4 kernel -- ramdisk
> > use both buffers and cached mem of the same size, thus
> > double the mem use.
> > mke2fs -m0 /dev/ram1
> > mount /dev/ram1 /mnt
> > dd if=/dev/zero of=/mnt/data bs=1k count=110000
> > cat /proc/meminfo will see that both buffers and
> > cached mem increase about 110M of size. More worse,
> > the cached mem won't be released untile the ramdisk
> > be umounted. I attach the meminfo and slabinfo before
>
> the "more worse" part is the only thing which is wrong. The fact cache
> also grows to 110M is expected and it won't change. With the
> blkdev-pagecache patch the cache will grow to 220M and it will shrink to
> 110M if you are low on memory (buffer cache will only be allocated for
> the superblock and inode metadata with ext2).

broken, clean 2.4.4 kernel with blkdev-pagecache-1 and o_direct-5 patch
mke2fs /dev/ram0; mount /dev/ram0 /mnt
VFS:can't find an ext2 filesystem on dev ramdisk(1,0)
mount:wrong fs type, bad option, bad superblock on /dev/ram0 ...
I miss something?

BTW, I noticed that the blkdev-pagecache had been submitted early in 2.4.5
pre1,
but not included in 2.4.5 final, 2.4.5 still has the bug -- can't release
mem unless
the ramdisk unmounted. Would this be considered not a problem or just a
bearable
side-effect for some elegant designs?

> use ramfs if you want zero ram duplication and you don't care about the
> physical representation on disk of your data in cache.
 ramfs's src code inode.c says it not for general use, so not try and I
can't find any
docs about how to use it.

> Try this patch to fix the "more worst part" (beware totally untested).
seems works. will do more tests though. thanks!

regard,

Zeng Yu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:19 EST