From: Pavel Machek <pavel@ucw.cz>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: Amit Gud <gud@eth.net>, alan <alan@clueserver.org>,
"Fao, Sean" <Sean.Fao@dynextechnologies.com>,
linux-kernel@vger.kernel.org
Subject: Re: Elastic Quota File System (EQFS)
Date: Fri, 25 Jun 2004 23:44:18 +0200 [thread overview]
Message-ID: <20040625214418.GB5907@elf.ucw.cz> (raw)
In-Reply-To: <200406251707.i5PH7KOw009004@eeyore.valparaiso.cl>
Hi!
> > > Case closed, anyway. It belongs in the kernel only if there is no
> > > reasonable way to do it in userspace.
> >
> > But... there's no reasonable way to do this in userspace.
>
> Let's see...
>
> > Two pieces of kernel support are needed:
> >
> > 1) some way to indicate "this file is elastic" (okay perhaps xattrs
> > can do this already)
>
> Or just a list of elastic files in ~/.elastic. Even better, could mark them
> as "Just delete", "compress"; could go as far as giving (fallback?) globs
> to select files for each treatment ("If space gets tight, delete *~ files,
> and compress *.tex that haven't been read in a week"). Sounds like a fun
> Perl project...
.elastic is ugly but okay.
> > and either
> >
> > 2a) file selection/deletion in kernel
>
> A daemon or cron job running as root can do that just fine. Or you can set
> it up for your own files.
If I make it cron job once an hour, users will still get -ENOSPC for
up-to hour. You can make it down to second, but you'll still get
-ENOSPC from time to time. If you want to eliminate -ENOSPC
altogether, you'll delete file from kernel just before returning
-ENOSPC and retry operation.
> > 2b) assume that disk does not fill up faster than 1GB/sec, allways
> > keep 1GB free, make "deleting" daemon poll each second [ugly,
> > unreliable]
>
> Buy a larger disk. Make sure sum of all hard quotas is less than filesystem
> size. Need that anyway; so it reduces to a one-user problem with per-user
> solutions.
Well, having sum of all hard quotas > filesystem size was point of
this excersize...
> > BTW 2c) would be also usefull for undelete. Unfortunately 2c looks
> > very complex, too; it might be easier to do 2a than 2c.
>
> As said, all this buys very little for a lot of hairy code in the kernel,
> which will be rarely used (and whose bugs will show up when it is badly
> needed to work right). Besides, I strongly oppose automatic file
It may be little gain for lots of effort. I'm just trying to say that
it is not complete nonsense.
I guess we are basically agreeing with each other... It may make nice
student project, and if patch is very non-intrusive, I guess its
okay. If it turns to be hairy, its not worth bothering.
> that, so you have no right to know", no "undelete deleted files, but only
> sometimes; it just might still be around, but if space got tight it isn't"
> (this is even worse...))
Well, few times I wished unix had undelete... It actually *has* one,
and its called power button if you are realize your mistake within 5
seconds.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2004-06-25 21:44 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-25 14:02 Elastic Quota File System (EQFS) Amit Gud
2004-06-25 14:23 ` Fao, Sean
2004-06-25 14:44 ` Horst von Brand
2004-06-25 16:25 ` Pavel Machek
2004-06-25 16:44 ` Alan
2004-06-25 17:35 ` Amit Gud
2004-06-25 20:22 ` Fao, Sean
2004-06-25 23:50 ` Kevin Fox
2004-06-26 4:03 ` Amit Gud
2004-06-26 21:36 ` Fao, Sean
2004-06-26 23:16 ` Stephen Wille Padnos
2004-06-27 1:44 ` Fao, Sean
2004-06-28 13:43 ` Rob Couto
2004-06-25 21:36 ` Pavel Machek
2004-06-25 17:07 ` Horst von Brand
2004-06-25 18:44 ` Amit Gud
2004-06-25 21:44 ` Pavel Machek [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-23 15:53 Amit Gud
2004-06-23 17:53 ` Mark Watts
[not found] ` <1088016048.15211.10.camel@sage.kitchen>
2004-06-24 9:28 ` Amit Gud
2004-06-24 11:50 ` Olaf Dabrunz
2004-06-24 14:04 ` Sam Elstob
2004-06-24 13:51 ` Olaf Dabrunz
2004-06-24 14:17 ` Pavel Machek
2004-06-24 19:58 ` Fao, Sean
2004-06-24 20:28 ` Timothy Miller
2004-06-24 20:30 ` Timothy Miller
2004-06-24 21:30 ` Pavel Machek
2004-06-24 20:51 ` alan
2004-06-24 22:03 ` Pavel Machek
2004-06-24 23:07 ` alan
2004-06-25 0:15 ` Pavel Machek
2004-06-25 11:57 ` Fao, Sean
2004-06-25 12:07 ` Josh Boyer
2004-06-25 19:34 ` Jörn Engel
2004-06-25 17:37 ` Timothy Miller
2004-06-25 18:44 ` Amit Gud
2004-06-26 12:00 ` Helge Hafting
2004-06-25 19:09 ` Amit Gud
2004-06-30 13:02 ` Olaf Dabrunz
2004-06-25 7:52 ` Lionel Bouton
2004-06-27 18:18 ` V13
2004-06-27 19:42 ` Lionel Bouton
2004-06-28 15:34 ` Amit Gud
2004-06-25 3:04 ` Bernd Eckenfels
2004-06-23 20:37 ` Rik van Riel
2004-06-23 15:48 gud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040625214418.GB5907@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=Sean.Fao@dynextechnologies.com \
--cc=alan@clueserver.org \
--cc=gud@eth.net \
--cc=linux-kernel@vger.kernel.org \
--cc=vonbrand@inf.utfsm.cl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.