Well, when linux is running, you can of course use shm.
But when linux is running the point is moot, the kernel's
in memory. I don't really see your point there, it's sort of
a prerequisite for booting:)
Putting filesystem stuff in there is probably not too rewarding.
I'm guessing the most consistently accessed directories
are /etc and the bins. Etc you want on your hard drive, and
the bins are way too large. Some smart pathing priotities or a
mounting-over-an-existing-directory trick would enable you to
do so fairly safely, except updating executables wouldn't
update the ram copy, or only do so. But for executables I
doubt there's much use; the common stuff probably gets
cached anyhow, though I don't know about that.
Hrm... I've been wondering how much of a hard drive relief
it would be to put the metadata of the top x most accessed
files or just up to y MB in of it ramdisk. Considering hard
drive flutter is a major bummer to performance these days,
doing a flutter for common filesystem *meta*data seems
rather silly - and a /lot/ of programs stat() way like crazy.
Or maybe that's just my find-abusing self.
On not enough coffee, probably.
It seems a memory-cheap way to avoid unnecessary
accesses - although it would probably have to hook into
general FS code, so not be practical. I mean, if you're
going to touch that, you may as well make a decent
On Thu, 21 Oct 2004 21:34:04 +0200, omghaai <omghaai@...> wrote:
> I've been looking into ramdisks lately and was wondering what the
> maximum size of a ramdisk can be, the most I've seen so far is 10Mb.
> If limited to 10Mb, what would benifit the system the most, by putting
> it in the ramdisk (for an average workstation)?
> If not limited to 10Mb, is it possible to put the whole kernel in a
> ramdisk and would it be worth it?
email@example.com mailing list