Ridiculous idea: Cache as ramdisk?

[Sander Vesik]

J. Kanowitz <jkanowitz at xxxxxxxx> wrote:
> 
> Matt saw the 'either you care or you don't' separation that I did, though
> if something somewhere were implemented as a timer, then I assume this
> sort of data could get a magic value of 0 to hang in RAM forever, while
> some other fun use might someday be found for 'priorities' between this
> case and defaults.  (I'm pretty sure it doesn't work that way, I'm not
> applying brainpower, I'm just clarifying the initial case to explain what
> I was on about.) 

It depends really. An explicit "flush" or "checkpoint" op on it - or
explict syncronisation - may well be acceptable level of "caring". Its
more than MFS based /tmp, where you have to figure out what "syncing"
means and use normal filesystem tools like say... tar.

[snip]

> 
> Of course, I forgot to take a multiuser perspective here, and if you're
> doing this *because* something's going to make a mess, you probably aren't
> going to remember to 'rm' the files afterwards, there might need to be
> quotas per-user (hm, so now that's tracking by process and by owner/user?),
> you'd want some other utility that would be a rough hybrid of newfs/unmount
> and rm -rf /tmp (making, say, all a user's 'blazed' files disappear and 
> freeing the associated memory), and it all starts to sound as half-baked 
> as it really was. ;)  

if you can explicitly allocate per process tree branch / logical partition
swap you wouldn't have teh problem. all users woul get their own jail and
a swap area allocated from vinum and won't be able to hog others resources.

> 
> The discussion is great stuff, in any case.  Right now I need to wake up
> enough to actually start learning from it again!
> 
> -Joe "Floid" Kanowitz

-- 
	Sander

+++ Out of cheese error +++