From: Stephen Wille Padnos <spadnos@sover.net>
To: "Fao, Sean" <sean.fao@capitalgenomix.com>
Cc: Amit Gud <gud@eth.net>,
"Fao, Sean" <Sean.Fao@dynextechnologies.com>,
Alan <alan@clueserver.org>, Pavel Machek <pavel@ucw.cz>,
Horst von Brand <vonbrand@inf.utfsm.cl>,
linux-kernel@vger.kernel.org
Subject: Re: Elastic Quota File System (EQFS)
Date: Sat, 26 Jun 2004 19:16:47 -0400 [thread overview]
Message-ID: <40DE03DF.7090404@sover.net> (raw)
In-Reply-To: <40DDEC76.8060101@capitalgenomix.com>
Fao, Sean wrote:
> Amit Gud wrote:
>
>> Fao, Sean wrote:
>>
>>> Amit Gud wrote:
>>>
>>>> It cannot be denied that there _are_ applications for such a system
>>>> that we already discussed and theres a class of users who will find
>>>> the system useful.
>>>
>>> I personally see no use whatsoever. Why not just allocate 100% of
>>> the file system to everybody and ignore quota's, entirely? Each
>>> user will use whatever he/she requires and when space starts to run
>>> out, users will manually clean up what they don't need.
>>
>> We should get our basics right first. We _do_ need quotas!! Without
>> any quota system how are we going to avoid a malicious user from
>> taking away all the space to keep other people starving? In EQFS also
>> this can happen, but we are giving *controlled flexibility* to the
>> user. He is having some stretching power but not beyond a certain
>> limit. And do you think users are sincere enough to clean up there
>> files when they are done?
>
> And I suppose you think that users will be sincere enough to mark
> files as elastic? I, for one, already said that I absolutely would
> *not* mark a single file as elastic. If I'm using 110 MB and you need
> an additional 10 MB for storage, you won't be getting it from me
> because I don't want to come in some morning to find that a file has
> disappeared.
>
> The system that you're asking for is a system without quotas. Think
> about what you're saying.
I think you missed one of the main points - you don't get any extra
space until you mark some of your files as elastic.
You're right - under this system, nobody would get any space from
deletion of your files because you would use the system as a normal hard
quota system - you would mark no files as elastic, and would therefore
be limited to your quota (in the example you gave, you would not be
using 110M, because your quota would have limited you to 100M). If you
were so kind as to mark something as elastic (say, that recently
doneloaded install tarball of the Gimp), then you would remove the
storage taken by those files from your quota usage and would have more
space available, with the risk that the elastic files might not stick
around.
Under no circumstance would you lose any file that fits under your quota.
>>> I am totally against the automatic deletion of files and believe
>>> that all users will _eventually_ walk in on a Monday morning to find
>>> out that the OS took it upon itself to delete a file that was
>>> flagged as elastic, that shouldn't have been.
>>
>> User is the king, he decides what files should be elastic and what
>> not. This can always be controlled.
>
> Controlled how? Who is anybody to inform me of what files I
> need/don't need?
Controlled by you using one of the methods that have been suggested:
a .elastic file/directory structure
/scratch/ space usage
a filesystem that can keep track of these things, and a program like chmod
xattrs and other userspace tools
etc.
- Steve
next prev parent reply other threads:[~2004-06-26 23:17 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 [this message]
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
-- 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=40DE03DF.7090404@sover.net \
--to=spadnos@sover.net \
--cc=Sean.Fao@dynextechnologies.com \
--cc=alan@clueserver.org \
--cc=gud@eth.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=sean.fao@capitalgenomix.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox