Ouch.. yes you had to do stuff like that in the old days but it's very
cumbersome and inefficient compared to ramfs for what you're trying to do.
> 1. I presume the kernel is clever enough to not cache any
> files from these filesystems? Would it ever need to?
You always need to "cache" pages read. Because a page is the smallest
possible granularity for the MMU, and a block-based filesystem does not
need to be page-aligned, so it's impossible to do it otherwise in a
general way.
> 3. If I've no backing store (harddisk?) is there any advantage
> of using tmpfs instead of ramfs? Also does tmpfs need a
> backing store?
I don't know what tmpfs does actually, but if it is like you suggest (a
ramfs that can be swapped out ?) then you don't need it obviously (since
you don't have any swap).
ramfs simply inserts any files written into the kernels cache and tells it
not to forget it. it can't get much more simple than that.
> 5. Can you set size limits on ramfs/tmpfs/memfs?
i don't think you can set a limit in the current ramfs implementation but
it would not be particularly difficult to make it work I think
> 6. Is a ramdisk resizable like the others. If so, do you have
> to delete/recreate or umount/resize a fs (e.g. ext2) every
> time it's resized? Do ramfs/tmpfs/memfs do this transparently?
> Are ramdisks resizable in kernel 2.2?
ramfs does not need any "resizing" because there is no filesystem behind
it. there is only the actual file data and metadata in the cache itself.
if you delete a file, it disapperas, if you create a new one new pages are
brought in.
> 7. What's memfs?
> 8. Is there a way I can get transparent compression like I now
> have using a ramdisk+ext2+e2compr with ramfs et al?
you could try using jffs2 on a RAM-simulated MTD partition. i think that
would work but i have not tried it..
> 9. Apart from this transparent compression, is there any other
> functionality ext2 would have over ramfs for e.g, for /tmp
> & /var? Also would ramfs have less/more speed over ext2?
ramfs has all the bells and whistles you need except size limiting. and
obviously its faster than simulating a harddisk in ram and using ext2 on
it..
-bw
-
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/