Re: Elastic Quota File System (EQFS)

Pavel Machek
2004-06-24T21:34:11Z

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!