Messages in this thread | | | Date | Thu, 24 Jun 2004 23:30:41 +0200 | From | Pavel Machek <> | Subject | Re: Elastic Quota File System (EQFS) |
| |
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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |