From: Olaf Dabrunz <od@suse.de>
To: Sam Elstob <samelstob@fastmail.fm>
Cc: linux-kernel@vger.kernel.org, Amit Gud <gud@eth.net>
Subject: Re: Elastic Quota File System (EQFS)
Date: Thu, 24 Jun 2004 15:51:23 +0200 [thread overview]
Message-ID: <20040624135123.GB3614@suse.de> (raw)
In-Reply-To: <40DADF72.5060308@fastmail.fm>
On 24-Jun-04, Sam Elstob wrote:
> Amit
>
> I agree that the situation with 10000+ users is where such a filesystem
> becomse useful. It is the difference between actual disk usage and sum
> of all disk quota that provides the elastisicty.
>
> Imagine an ISP providing free mail with an advertised quota of 1GB per
> user. With 100,000 users, 100TB of storage would be needed. However,
> it is likely that most users would not use their full quota meaning a
> lot of wasted storage capacity, at the expense of the mail provider.
> What if the EFS could allow the sum of all advertised quotas to total
> more than the actual online disk capacity. Assuming average quota usage
> settles down and doesn't suddenly change on mass the actual online
> storage capacity of the system could be much lower (and thus cheaper)
> than the case where every user is at full quota. When the actual disk
> usage reaches, say 70%, of the attached capacity the administrator could
> be notified and action taken e.g. attach more disks and extend the
> volume, or backup and delete dead accounts.
This case is easily solved without any new mechanism. Simply assign a
quota of 1GB to each user while providing physical disk space only for
the expected filling + free space margin. Handle additional space
requirements as you described above.
What Amid tries to solve is obviously a different "scenario": how to put
more files on the disks than fit in the physically available space.
He tries to do that by
- squeezing in more data by compressing other data
- deleting files
- backing up files
And he provides a mechanism how a user can buy more space by marking
other files as "shrink/delete/back up at filesystems discretion". So in
effect he says: buy more space by marking files as "not needed, may be
removed (deleted or moved to some unreachable place) at any time". Then
I would rather opt to "clean up" my files myself whenever I need more
space within my quota.
(The compression case is actually not working out, since it will only
get back as much space as the compression achieves. So the elastic quota
may only be expanded by the space saved when the file is compressed. To
find out this ratio, you have to compress the file. But then you can as
well have your filesystem transparently compress the file.)
> I'm talking about the case where large (10000>) numbers of users are
> involved with a habit of using less than some advertised quota.
> Obviously the adverised quota is still available to those who want it,
> but overall the necessary disk space is less than the sum of all
> advertised disk quotas.
>
> Sam Elstob
--
Olaf Dabrunz (od/odabrunz), SUSE Linux AG, Nürnberg
next prev parent reply other threads:[~2004-06-24 13:52 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-23 15:53 Elastic Quota File System (EQFS) 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2004-06-25 14:02 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
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=20040624135123.GB3614@suse.de \
--to=od@suse.de \
--cc=gud@eth.net \
--cc=linux-kernel@vger.kernel.org \
--cc=samelstob@fastmail.fm \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox