Re: ramdisk

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
scheduler:P


--Bart


On Thu, 21 Oct 2004 21:34:04 +0200, omghaai <[email protected]> wrote:
> Hi.
> 
> 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 protected] mailing list