Ridiculous idea: Cache as ramdisk?

[J. Kanowitz]

In article <1064363252.591086 at xxxxxxxxxxxxxxxxxxx>, Sander Vesik wrote:

> nope. More like a "write through" union mount of a MFS and real filesystem
> with api for per-file policies.

Hm, that's an interesting way of looking at it.  I think.  Obviously I
don't actually 'want' anything, but the original vague idea did have reads 
seeing the same (RAM-held) treatment as writes, in a... "per-process 
context?"

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.) 

The example I'd use would be something like dropping to single-user and
running 'blaze make buildworld,' where this mythical 'blaze' command
would launch a subshell, I guess, and somehow that subshell and all its
children(?) would have to get this special treatment.  Instead of 
explicitly mounting /usr/obj MFS or similar, it'd "just work" non-modally,
and then running 'make installworld' would copy all the files under 
'normal' conditions, and see them committed to the FS where they actually
belong, while the stuff in /usr/obj would just disappear after the 
reboot.

That's still not a great example (are there any?), because it's trivial
to just mount /usr/obj MFS, but there are the little cases where, as
with the 'unzip,' you're just lazy and wouldn't be bothered to untangle 
dumb hardcoded paths or permissions on a tmpfs. 

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. ;)  
 
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