Re: Elastic Quota File System (EQFS)

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >>>What action should be taken can be specified by the user while making the
> >>>files elastic. He can either opt to delete the file, compress it or move 
> >>>it
> >>>to some place (backup) where he know he has write access. The 
> >>>corresponding
> >>>     
> >>>
> >>- having files disappear at the discretion of the filesystem seems to be
> >> bad behaviour: either I need this file, then I do not want it to just
> >> disappear, or I do not need it, and then I can delete it myself.
> >>   
> >>
> >
> >
> >Actually, think .o or mozilla cache files... You don't need them, but if 
> >you have them,
> >things are faster.
> > 
> >
> I fail to understand the point you're trying to make.  Are you 
> suggesting that a feature doesn't necessarily have to be implemented, 
> just because it's there?  If so, the proposed idea on the "elastic" file 
> system differs greatly.  Cached content, for instance, speeds up the 
> browsing experience *without* hindering the ability of the application 
> to function normally.  Caching is a true enhancement --in most 
> circumstances.  I can personally see no way to implement EQFS without 
> greatly exasperating end users with its shortcomings.

Okay, lets make it explicit.

On one school server, theres 10MB quota. (Okay, its admins are
BOFHs^H^H^H^H^HSISAL). Everyone tries to run mozilla there (because
its installed as default!), and immediately fills his/her quota with
cache files, leading to failed login next time (gnome just will not
start if it can't write to ~).

Imagine mozilla automatically marking cache files "elastic".

That would solve the problem -- mozilla caches would go away when disk
space was demanded, still mozilla's on-disk caching would be effective
when there is enough disk space.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!