Greetings,
I think I should discuss this in the list...
Recently I'm into developing an Elastic Quota File System (EQFS). This
file system works on a simple concept ... give it to others if you're not
using it, let others use it, but on the guarantee that you get it back when
you need it!!
Here I'm talking about disk quotas. In any typical network, e.g.
sourceforge, each user is given a fixed amount of quota. 100 Mb in case of
sourceforge. 100 Mb is way over some project requirements and too small for
some projects. EQFS tries to solve this problem by exploiting the users'
usage behavior at runtime. That is the user's quota which he doesn't need
is given to the users who need it, but on 100% assurance that the originl
user can any time reclaim his/her quota.
Before getting into implementation details I want to have public opinion
about this system. All EQFS tries to do is it maximizes the disk space
usage, which otherwise is wasted if the user doesn't really need the
allocated user..on the other hand it helps avoid the starvation of the user
who needs more space. It also helps administrator to get away with the
problem of variable quota needs..as EQFS itself adjusts according to the
user needs.
regs,
AG
http://www.ddsl.net
> Greetings,
>
> I think I should discuss this in the list...
>
> Recently I'm into developing an Elastic Quota File System (EQFS). This
> file system works on a simple concept ... give it to others if you're not
> using it, let others use it, but on the guarantee that you get it back when
> you need it!!
How do you intend to guarantee this?
Randomly deleting a users files to free up disk space is a Bad (tm) idea, so
what other mechanism are you going to employ?
On Wed, 23 Jun 2004, Amit Gud wrote:
> That is the user's quota which he doesn't need is given to the users who
> need it, but on 100% assurance that the originl user can any time
> reclaim his/her quota.
Where do you put to store the "extra data" of the over-quota
users if it can't be stored on the filesystem ?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Ok, this is what I propose:
Lets say there are just 2 users with 100 megs of individual quota, user
A is using 20 megs and user B is running out of his quota. Now what B could
do is delete some files himself and make some free space for storing other
files. Now what I say is instead of deleting the files, he declares those
files as elastic.
Now, moment he makes that files elastic, that much amount of space is added
to his quota. Here Mark Cooke's equation applies with some modifications:
N no. of users,
Qi allocated quota of ith user
Ui individual disk usage of ith user ( should be <= allocated quota of ith
user ),
D disk threshold; thats the amount of disk space admin wants to allow the
users to use (should be >= sum of all users' allocated quota, i.e. summation
Qi ; for i = 0 to N - 1).
Total usage of all the users (here A & B) should be at _anytime_ less than
D. i.e. summation Ui <= D; for i = 0 to N - 1.
The point to note here is that we are not bothering how much quota has been
allocated to an individual user by the admin, but we are more interested in
the usage pattern followed by the users. E.g. if user B wants additional
space of say 25 megs, he picks up 25 megs of his files and 'marks' them
elastic. Now his quota is increased to 125 megs and he can now add more 25
megs of files; at the same time allocated quota for user A is left
unaffected. Applying the above equation total usage now is A: 20 megs, B:
125 megs, now total 145 <= D, say 200 megs. Thus this should be ok for the
system, since the usage is within bounds.
Now what happens if Ui > D? This can happen when user A tries to recliam his
space. i.e. if user A adds say more 70 megs of files, so the total usage is
now - A: 90 megs, B: 125 megs; 215 ! <= D. The moment the total usage
crosses the value, 'action' will be taken on the elastic files. Here elastic
files are of user B so only those will be affected and users A's data will
be untouched, so in a way this will be completely transparent to user A.
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
action will be taken until the threshold is met.
Will this work?? We are relying on the 'free' space ( i.e. D - Ui ) for the
users to benefit. The chances of having a greater value for D - Ui increases
with the increase in the number of users, i.e. N. Here we are talking about
2 users but think of 10000+ users where all the users will probably never
use up _all_ the allocated disk space. This user behavior can be well
exploited.
EQFS can be best fitted in the mail servers. Here e.g. I make whole
linux-kernel mailing list elastic. As long as Ui <= D I get to keep all the
messages, whenever Ui > D, messages with latest dates will be 'acted' upon.
For variable quota needs, admin can allocate different quotas for different
users, but this can get tiresome when N is large. With EQFS, he can allocate
fixed quota for each user ( old and new ) , set up a value for D and relax.
The users will automatically get the quota they need. One may ask that this
can be done by just setting up value of D, checking it against summation Ui
and not allocating individual quotas at all. But when summation Ui crosses D
value, whose file to act on? Moreover with both individual quotas and D, we
give users 'controlled' flexibility just like elastic - it can be stretched
but not beyond a certain range.
What happens when an user tries to eat up all the free ( D - Ui ) space?
This answer is implementation dependent because you need to make a decision:
should an user be allowed to make a file elastic when Ui == D . I think by
saying 'yes' we eliminate some users' mischief of eating up all free space.
Queries, comments, suggestions welcome.
regs,
AG
> On Wed, 2004-06-23 at 18:53, Mark Watts wrote:
> > > Greetings,
> > >
> > > I think I should discuss this in the list...
> > >
> > > Recently I'm into developing an Elastic Quota File System (EQFS). This
> > > file system works on a simple concept ... give it to others if you're
not
> > > using it, let others use it, but on the guarantee that you get it back
when
> > > you need it!!
> >
> > How do you intend to guarantee this?
> > Randomly deleting a users files to free up disk space is a Bad (tm)
idea, so
> > what other mechanism are you going to employ?
>
> Hi Mark, Amit,
>
> Simple example of a flexible quota scheme:
>
> N users with Q megabytes of guaranteed quota
> D total megs of disk storage
> The difference D - N*Q is the amount you can be flexible with.
>
>
> The above is a somewhat different scheme than the 'give your unused
> quota back to others' part of Amit's post though.
>
> If Amit does actually mean to have a situation where the remaining
> guaranteed quota is less than the actual remaining free space, there is
> *no way* to satisfy the guarantee.
>
> Imagine the worst case scenario if all users suddenly want their
> guaranteed quota. The only way to free up space is deleting files from
> over-quota users - something which would be unacceptable operationally,
> IMHO.
>
>
> That said, I'll read your tech description with interest when it comes
> out,
>
> Mark
>
On 24-Jun-04, Amit Gud wrote:
> Ok, this is what I propose:
>
> Lets say there are just 2 users with 100 megs of individual quota, user
> A is using 20 megs and user B is running out of his quota. Now what B could
> do is delete some files himself and make some free space for storing other
> files. Now what I say is instead of deleting the files, he declares those
> files as elastic.
>
> Now, moment he makes that files elastic, that much amount of space is added
> to his quota. Here Mark Cooke's equation applies with some modifications:
> N no. of users,
> Qi allocated quota of ith user
> Ui individual disk usage of ith user ( should be <= allocated quota of ith
> user ),
> D disk threshold; thats the amount of disk space admin wants to allow the
> users to use (should be >= sum of all users' allocated quota, i.e. summation
> Qi ; for i = 0 to N - 1).
>
> Total usage of all the users (here A & B) should be at _anytime_ less than
> D. i.e. summation Ui <= D; for i = 0 to N - 1.
>
> The point to note here is that we are not bothering how much quota has been
> allocated to an individual user by the admin, but we are more interested in
> the usage pattern followed by the users. E.g. if user B wants additional
> space of say 25 megs, he picks up 25 megs of his files and 'marks' them
> elastic. Now his quota is increased to 125 megs and he can now add more 25
> megs of files; at the same time allocated quota for user A is left
> unaffected. Applying the above equation total usage now is A: 20 megs, B:
> 125 megs, now total 145 <= D, say 200 megs. Thus this should be ok for the
> system, since the usage is within bounds.
>
> Now what happens if Ui > D? This can happen when user A tries to recliam his
> space. i.e. if user A adds say more 70 megs of files, so the total usage is
> now - A: 90 megs, B: 125 megs; 215 ! <= D. The moment the total usage
> crosses the value, 'action' will be taken on the elastic files. Here elastic
> files are of user B so only those will be affected and users A's data will
> be untouched, so in a way this will be completely transparent to user A.
> 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.
Since my idea of which files I need and which I do not need changes
over time, I believe it is far better that I can control which files I
need and which I do not need whenever other constraints (e.g. quota
filled up) make this decision necessary. Also, then I can opt to try
to convince someone to increase my quota.
- moving the file to some other place (backup) does not seem to be a
viable option:
- If the backup media is always accessible, then why can't the user
store the "elastic" files there immediately?
-> advantages:
- the user knows where his file is
- applications that remember the path to a file will be able to
access it
- If the backup media will only be accessible after manually inserting
it into some drive, this amounts to sending an E-Mail to the backup
admin and then pass a list of backup files to the backup software.
But now getting the file back involves a considerable amount of
manual and administrative work. And it involves bugging the backup
admin, who now becomes the bottleneck of your EQFS.
So this narrows down to the effective handling of backup procedures and
the effective administration of fixed quotas and centralization of data.
If you have many users it is also likely that there are more people
interested in big data-files. So you need to help these people organize
themselves e.g. by helping them to create mailing-list, web-pages or
letting them install servers that makes the data centrally available
with some interface that they can use to select parts of the data.
I would rather suggest that if the file does not fit within a given
quota, the user should apply for more quota and give reasons for that.
I believe that flexible or "elastic" allocation of ressources is a good
idea in general, but it only works if you have cheap and easy ways to
control both allocation and deallocation. So in the case of CBQ in
networks this works, since bandwidth can easily and quickly be allocated
and deallocated.
But for filesystem space this requires something like a "slower (= less
expensive), bigger, always accessible" third level of storage in the
"RAM, disk, ..." hierarchy. And then you would need an easy or even
transparent way to access files on this third level storage. And you
need to make sure that, although you obviously *need* the data for
something, you still can afford to increase retrieval times by several
orders of magnitude at the discretion of the filesystem.
But usually all this can be done by scripts as well.
Still, there is a scenario and a combination of features for such a
filesystem that IMHO would make it useful:
- Provide allocation of overquota as you described it.
- Let the filesystem move (parts of) the "elastic" files to some
third-level backing-store on an as-needed basis. This provides you
with a not-so-cheap (but cheaper than manual handling) resource
management facility.
Now you can use the third-level storage as a backing store for
hard-drive space, analoguous to what swap-space provides for RAM. And
you can "swap in" parts of files from there and cache them on the hard
drive. So "elastic" files are actually files that are "swappable" to
backing store.
This assumes that the "elastic" files meet the requirements for a
"working set" in a similar fashion as for RAM-based data. I.e. the swap
operations need only be invoked relatively seldom.
If this is not the case, your site/customer needs to consider buying
more hard drive space (and maybe also RAM).
The tradeoff for the user now is:
- do not have the big file(s) OR
- have them and be able to use them in a random-access fashion from
any application, but maybe only with a (quite) slow access time,
but without additional administrative/manual hassle
Maybe this is a good tradeoff for a significant amount of users. Maybe
there are sites/customers that have the required backing store (or would
consider buying into this). I do not know. Find a sponsor, do some field
research and give it a try.
> action will be taken until the threshold is met.
>
> Will this work?? We are relying on the 'free' space ( i.e. D - Ui ) for the
> users to benefit. The chances of having a greater value for D - Ui increases
> with the increase in the number of users, i.e. N. Here we are talking about
> 2 users but think of 10000+ users where all the users will probably never
> use up _all_ the allocated disk space. This user behavior can be well
> exploited.
>
> EQFS can be best fitted in the mail servers. Here e.g. I make whole
> linux-kernel mailing list elastic. As long as Ui <= D I get to keep all the
> messages, whenever Ui > D, messages with latest dates will be 'acted' upon.
>
> For variable quota needs, admin can allocate different quotas for different
> users, but this can get tiresome when N is large. With EQFS, he can allocate
> fixed quota for each user ( old and new ) , set up a value for D and relax.
> The users will automatically get the quota they need. One may ask that this
> can be done by just setting up value of D, checking it against summation Ui
> and not allocating individual quotas at all. But when summation Ui crosses D
> value, whose file to act on? Moreover with both individual quotas and D, we
> give users 'controlled' flexibility just like elastic - it can be stretched
> but not beyond a certain range.
>
> What happens when an user tries to eat up all the free ( D - Ui ) space?
> This answer is implementation dependent because you need to make a decision:
> should an user be allowed to make a file elastic when Ui == D . I think by
> saying 'yes' we eliminate some users' mischief of eating up all free space.
>
> Queries, comments, suggestions welcome.
>
> regs,
> AG
>
> > On Wed, 2004-06-23 at 18:53, Mark Watts wrote:
> > > > Greetings,
> > > >
> > > > I think I should discuss this in the list...
> > > >
> > > > Recently I'm into developing an Elastic Quota File System (EQFS). This
> > > > file system works on a simple concept ... give it to others if you're
> not
> > > > using it, let others use it, but on the guarantee that you get it back
> when
> > > > you need it!!
> > >
> > > How do you intend to guarantee this?
> > > Randomly deleting a users files to free up disk space is a Bad (tm)
> idea, so
> > > what other mechanism are you going to employ?
> >
> > Hi Mark, Amit,
> >
> > Simple example of a flexible quota scheme:
> >
> > N users with Q megabytes of guaranteed quota
> > D total megs of disk storage
> > The difference D - N*Q is the amount you can be flexible with.
> >
> >
> > The above is a somewhat different scheme than the 'give your unused
> > quota back to others' part of Amit's post though.
> >
> > If Amit does actually mean to have a situation where the remaining
> > guaranteed quota is less than the actual remaining free space, there is
> > *no way* to satisfy the guarantee.
> >
> > Imagine the worst case scenario if all users suddenly want their
> > guaranteed quota. The only way to free up space is deleting files from
> > over-quota users - something which would be unacceptable operationally,
> > IMHO.
> >
> >
> > That said, I'll read your tech description with interest when it comes
> > out,
> >
> > Mark
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Olaf Dabrunz (od/odabrunz), SUSE Linux AG, Nürnberg
Olaf Dabrunz wrote:
> On 24-Jun-04, Amit Gud wrote:
>
>>Ok, this is what I propose:
>>
>> Lets say there are just 2 users with 100 megs of individual quota, user
>>A is using 20 megs and user B is running out of his quota. Now what B could
>>do is delete some files himself and make some free space for storing other
>>files. Now what I say is instead of deleting the files, he declares those
>>files as elastic.
>>
>>Now, moment he makes that files elastic, that much amount of space is added
>>to his quota. Here Mark Cooke's equation applies with some modifications:
>>N no. of users,
>>Qi allocated quota of ith user
>>Ui individual disk usage of ith user ( should be <= allocated quota of ith
>>user ),
>>D disk threshold; thats the amount of disk space admin wants to allow the
>>users to use (should be >= sum of all users' allocated quota, i.e. summation
>>Qi ; for i = 0 to N - 1).
>>
>>Total usage of all the users (here A & B) should be at _anytime_ less than
>>D. i.e. summation Ui <= D; for i = 0 to N - 1.
>>
>>The point to note here is that we are not bothering how much quota has been
>>allocated to an individual user by the admin, but we are more interested in
>>the usage pattern followed by the users. E.g. if user B wants additional
>>space of say 25 megs, he picks up 25 megs of his files and 'marks' them
>>elastic. Now his quota is increased to 125 megs and he can now add more 25
>>megs of files; at the same time allocated quota for user A is left
>>unaffected. Applying the above equation total usage now is A: 20 megs, B:
>>125 megs, now total 145 <= D, say 200 megs. Thus this should be ok for the
>>system, since the usage is within bounds.
>>
>>Now what happens if Ui > D? This can happen when user A tries to recliam his
>>space. i.e. if user A adds say more 70 megs of files, so the total usage is
>>now - A: 90 megs, B: 125 megs; 215 ! <= D. The moment the total usage
>>crosses the value, 'action' will be taken on the elastic files. Here elastic
>>files are of user B so only those will be affected and users A's data will
>>be untouched, so in a way this will be completely transparent to user A.
>>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.
>
> Since my idea of which files I need and which I do not need changes
> over time, I believe it is far better that I can control which files I
> need and which I do not need whenever other constraints (e.g. quota
> filled up) make this decision necessary. Also, then I can opt to try
> to convince someone to increase my quota.
>
> - moving the file to some other place (backup) does not seem to be a
> viable option:
>
> - If the backup media is always accessible, then why can't the user
> store the "elastic" files there immediately?
> -> advantages:
> - the user knows where his file is
> - applications that remember the path to a file will be able to
> access it
>
> - If the backup media will only be accessible after manually inserting
> it into some drive, this amounts to sending an E-Mail to the backup
> admin and then pass a list of backup files to the backup software.
>
> But now getting the file back involves a considerable amount of
> manual and administrative work. And it involves bugging the backup
> admin, who now becomes the bottleneck of your EQFS.
>
> So this narrows down to the effective handling of backup procedures and
> the effective administration of fixed quotas and centralization of data.
>
> If you have many users it is also likely that there are more people
> interested in big data-files. So you need to help these people organize
> themselves e.g. by helping them to create mailing-list, web-pages or
> letting them install servers that makes the data centrally available
> with some interface that they can use to select parts of the data.
>
> I would rather suggest that if the file does not fit within a given
> quota, the user should apply for more quota and give reasons for that.
>
> I believe that flexible or "elastic" allocation of ressources is a good
> idea in general, but it only works if you have cheap and easy ways to
> control both allocation and deallocation. So in the case of CBQ in
> networks this works, since bandwidth can easily and quickly be allocated
> and deallocated.
>
> But for filesystem space this requires something like a "slower (= less
> expensive), bigger, always accessible" third level of storage in the
> "RAM, disk, ..." hierarchy. And then you would need an easy or even
> transparent way to access files on this third level storage. And you
> need to make sure that, although you obviously *need* the data for
> something, you still can afford to increase retrieval times by several
> orders of magnitude at the discretion of the filesystem.
>
> But usually all this can be done by scripts as well.
>
> Still, there is a scenario and a combination of features for such a
> filesystem that IMHO would make it useful:
>
> - Provide allocation of overquota as you described it.
> - Let the filesystem move (parts of) the "elastic" files to some
> third-level backing-store on an as-needed basis. This provides you
> with a not-so-cheap (but cheaper than manual handling) resource
> management facility.
>
> Now you can use the third-level storage as a backing store for
> hard-drive space, analoguous to what swap-space provides for RAM. And
> you can "swap in" parts of files from there and cache them on the hard
> drive. So "elastic" files are actually files that are "swappable" to
> backing store.
>
> This assumes that the "elastic" files meet the requirements for a
> "working set" in a similar fashion as for RAM-based data. I.e. the swap
> operations need only be invoked relatively seldom.
>
> If this is not the case, your site/customer needs to consider buying
> more hard drive space (and maybe also RAM).
>
>
> The tradeoff for the user now is:
> - do not have the big file(s) OR
> - have them and be able to use them in a random-access fashion from
> any application, but maybe only with a (quite) slow access time,
> but without additional administrative/manual hassle
>
> Maybe this is a good tradeoff for a significant amount of users. Maybe
> there are sites/customers that have the required backing store (or would
> consider buying into this). I do not know. Find a sponsor, do some field
> research and give it a try.
>
>
>>action will be taken until the threshold is met.
>>
>>Will this work?? We are relying on the 'free' space ( i.e. D - Ui ) for the
>>users to benefit. The chances of having a greater value for D - Ui increases
>>with the increase in the number of users, i.e. N. Here we are talking about
>>2 users but think of 10000+ users where all the users will probably never
>>use up _all_ the allocated disk space. This user behavior can be well
>>exploited.
>>
>>EQFS can be best fitted in the mail servers. Here e.g. I make whole
>>linux-kernel mailing list elastic. As long as Ui <= D I get to keep all the
>>messages, whenever Ui > D, messages with latest dates will be 'acted' upon.
>>
>>For variable quota needs, admin can allocate different quotas for different
>>users, but this can get tiresome when N is large. With EQFS, he can allocate
>>fixed quota for each user ( old and new ) , set up a value for D and relax.
>>The users will automatically get the quota they need. One may ask that this
>>can be done by just setting up value of D, checking it against summation Ui
>>and not allocating individual quotas at all. But when summation Ui crosses D
>>value, whose file to act on? Moreover with both individual quotas and D, we
>>give users 'controlled' flexibility just like elastic - it can be stretched
>>but not beyond a certain range.
>>
>>What happens when an user tries to eat up all the free ( D - Ui ) space?
>>This answer is implementation dependent because you need to make a decision:
>>should an user be allowed to make a file elastic when Ui == D . I think by
>>saying 'yes' we eliminate some users' mischief of eating up all free space.
>>
>>Queries, comments, suggestions welcome.
>>
>>regs,
>>AG
>>
>>
>>>On Wed, 2004-06-23 at 18:53, Mark Watts wrote:
>>>
>>>>>Greetings,
>>>>>
>>>>>I think I should discuss this in the list...
>>>>>
>>>>>Recently I'm into developing an Elastic Quota File System (EQFS). This
>>>>>file system works on a simple concept ... give it to others if you're
>>
>>not
>>
>>>>>using it, let others use it, but on the guarantee that you get it back
>>
>>when
>>
>>>>>you need it!!
>>>>
>>>>How do you intend to guarantee this?
>>>>Randomly deleting a users files to free up disk space is a Bad (tm)
>>
>>idea, so
>>
>>>>what other mechanism are you going to employ?
>>>
>>>Hi Mark, Amit,
>>>
>>>Simple example of a flexible quota scheme:
>>>
>>>N users with Q megabytes of guaranteed quota
>>>D total megs of disk storage
>>>The difference D - N*Q is the amount you can be flexible with.
>>>
>>>
>>>The above is a somewhat different scheme than the 'give your unused
>>>quota back to others' part of Amit's post though.
>>>
>>>If Amit does actually mean to have a situation where the remaining
>>>guaranteed quota is less than the actual remaining free space, there is
>>>*no way* to satisfy the guarantee.
>>>
>>>Imagine the worst case scenario if all users suddenly want their
>>>guaranteed quota. The only way to free up space is deleting files from
>>>over-quota users - something which would be unacceptable operationally,
>>>IMHO.
>>>
>>>
>>>That said, I'll read your tech description with interest when it comes
>>>out,
>>>
>>>Mark
>>>
>>
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to [email protected]
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at http://www.tux.org/lkml/
>
>
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.
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
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
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.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Pavel Machek wrote:
>>>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.
Sean
Fao, Sean wrote:
> Pavel Machek wrote:
>
>>>> 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.
>
> Sean
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Fao, Sean wrote:
> 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.
What you need is a small number of fast, expensive drives, and a large
array of cheap drives, and use the fast drives as a cache for user files.
But this is completely different from elastic quotas.
My solution to this would be to have large arrays of cheap disks and put
lots of RAM in the server and let RAM be the cache.
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!
On Thu, 24 Jun 2004, Pavel Machek wrote:
> 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.
How does Mozilla (or any process) react when its files are deleted from
under it? Would the file remain until all the open processes close the
file or would it just "disappear"? Would it delete entire directories or
just some of the files? How does it choose? (First up against the delete
when the drive space fills...)
Hi!
> > 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.
>
> How does Mozilla (or any process) react when its files are deleted from
> under it? Would the file remain until all the open processes close the
> file or would it just "disappear"?
Of course, if mozilla marked them "elastic" it should better be
prepared for they disappearance. I'd disappear them with simple
unlink(), so they'd physically survive as long as someone held them
open.
> Would it delete entire directories or
> just some of the files? How does it choose? (First up against the delete
> when the drive space fills...)
Probably just some of the files... Or you could delete directory, too,
if it was marked "elastic". What to delete first... probably file with
oldest access time? Or random file, with chance of being selected
proportional to file size?
I'm not implementing it, I'm just arguing that it is usefull.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Fri, 25 Jun 2004, Pavel Machek wrote:
> Hi!
>
> > > 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.
> >
> > How does Mozilla (or any process) react when its files are deleted from
> > under it? Would the file remain until all the open processes close the
> > file or would it just "disappear"?
>
> Of course, if mozilla marked them "elastic" it should better be
> prepared for they disappearance. I'd disappear them with simple
> unlink(), so they'd physically survive as long as someone held them
> open.
Hard to get the client to support a feature in an experimental file
system. You are more likely to handle this like a system policy than
something set by the client. (Especially since an app designed to fill
disk space could just mark its files as elastic to get around quotas.)
> > Would it delete entire directories or
> > just some of the files? How does it choose? (First up against the delete
> > when the drive space fills...)
>
> Probably just some of the files... Or you could delete directory, too,
> if it was marked "elastic". What to delete first... probably file with
> oldest access time? Or random file, with chance of being selected
> proportional to file size?
>
> I'm not implementing it, I'm just arguing that it is usefull.
I think that would make a bunch of headaches for the app designer.
Imaging having a cache directory with an indexed database in a directory
marked as elastic. What happens whenone part of the multi-file database
gets nuked in the middle on operation? You are going to have to
handle much more error conditions for weird special cases to deal with
files wandering away without having the app just halt. (Most programs I
have seen just halt when a file they need is not found.)
A better option in this case is to reduce the default size of Mozilla's
cache or expand the size of the quota for each user to deal with the added
space requirements.
If you are concerned about disk usage from caches, you can always create
a script that removes the cache(s) when the user logs out.
Hi!
> > Of course, if mozilla marked them "elastic" it should better be
> > prepared for they disappearance. I'd disappear them with simple
> > unlink(), so they'd physically survive as long as someone held them
> > open.
>
> Hard to get the client to support a feature in an experimental file
> system. You are more likely to handle this like a system policy than
> something set by the client. (Especially since an app designed to fill
> disk space could just mark its files as elastic to get around
> quotas.)
I believe application support is right thing to do... It may not be
the easiest thing to do, through.
> > > Would it delete entire directories or
> > > just some of the files? How does it choose? (First up against the delete
> > > when the drive space fills...)
> >
> > Probably just some of the files... Or you could delete directory, too,
> > if it was marked "elastic". What to delete first... probably file with
> > oldest access time? Or random file, with chance of being selected
> > proportional to file size?
> >
> > I'm not implementing it, I'm just arguing that it is usefull.
>
> I think that would make a bunch of headaches for the app designer.
> Imaging having a cache directory with an indexed database in a directory
> marked as elastic. What happens whenone part of the multi-file database
> gets nuked in the middle on operation? You are going to have to
> handle much more error conditions for weird special cases to deal with
> files wandering away without having the app just halt. (Most programs I
> have seen just halt when a file they need is not found.)
Well, that's arguably application bug. Anyway, noone says that right
thing to do is easy.
> A better option in this case is to reduce the default size of Mozilla's
> cache or expand the size of the quota for each user to deal with the added
> space requirements.
>
> If you are concerned about disk usage from caches, you can always create
> a script that removes the cache(s) when the user logs out.
That's not the right thing.. that way you loose caching effects around
logins even when there's plenty of space.
There's quite a lot of data -- at least on my systems -- that can be
removed with "only" loss of performance...
1) browser caches
2) package lists, downloaded packages
3) object files
heck, if you know you have reliable network connection 4), you could
even mark stuff like /usr/bin/mozilla elastic, and re-install it from
the network when it is needed... Doing anything more complex than 1)
requires extensive changes all around the kernel and userland, and
you'd probably not call that system unix any more.
I'm not saying that "elastic" feature should go into 2.6 or 2.8 or
whatever, but it still seems interesting to me.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
In article <001901c459cd$bc436e40$868209ca@home> you wrote:
> The point to note here is that we are not bothering how much quota has been
> allocated to an individual user by the admin, but we are more interested in
> the usage pattern followed by the users. E.g. if user B wants additional
> space of say 25 megs, he picks up 25 megs of his files and 'marks' them
> elastic. Now his quota is increased to 125 megs and he can now add more 25
> megs of files; at the same time allocated quota for user A is left
> unaffected.
I would better understand if you do not incease the quota, but simply dont
count the elastic files in the consumption.
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Pavel Machek wrote the following on 06/25/2004 12:03 AM :
>Of course, if mozilla marked them "elastic" it should better be
>prepared for they disappearance. I'd disappear them with simple
>unlink(), so they'd physically survive as long as someone held them
>open.
>
>
>
Doesn't work reliably : the deletion is done in order to reclaim space
that is needed now. You may want to retry unlinking files until you
reach the free space needed, but this is clearly a receipe for famine :
process can wait on writes an unspecified amount of time.
--
Lionel Bouton - inet6
---------------------------------------------------------------------
o Siege social: 51, rue de Verdun - 92158 Suresnes
/ _ __ _ Acces Bureaux: 33 rue Benoit Malon - 92150 Suresnes
/ /\ /_ / /_ France
\/ \/_ / /_/ Tel. +33 (0) 1 41 44 85 36
Inetsys S.A. Fax +33 (0) 1 46 97 20 10
>>A better option in this case is to reduce the default size of Mozilla's
>>cache or expand the size of the quota for each user to deal with the added
>>space requirements.
>>
>>If you are concerned about disk usage from caches, you can always create
>>a script that removes the cache(s) when the user logs out.
>>
>>
>
>That's not the right thing.. that way you loose caching effects around
>logins even when there's plenty of space.
>
>There's quite a lot of data -- at least on my systems -- that can be
>removed with "only" loss of performance...
>
>1) browser caches
>
>2) package lists, downloaded packages
>
>3) object files
>
>heck, if you know you have reliable network connection 4), you could
>even mark stuff like /usr/bin/mozilla elastic, and re-install it from
>the network when it is needed... Doing anything more complex than 1)
>requires extensive changes all around the kernel and userland, and
>you'd probably not call that system unix any more.
>
>
All the suggested benefits listed above could easily be implemented in a
script. For instance, one could design a script that checks the amount
of disk space at logout. If the amount of disk space remaining is less
than X (where X is value predefined by an administrator), the script
could _suggest_ that corrective action be taken and allow the *user* to
_decide_ what he/she wants to delete/move.
In a workstation environment, my honest opinion is that quota's are set
entirely too low if you're running that close to your limit. On a
server, I do not see deleting files at the decision of the OS, to be
beneficial. Nor do I see any reason to develop the suggested FS to
implement what should be taken care of by a knowledgeable administrator.
The idea of an elastic file system is interesting until you start
considering how it would be implemented and what affects it would have
in a production environment.
Sean
On Thu, 2004-06-24 at 19:15, Pavel Machek wrote:
> > A better option in this case is to reduce the default size of Mozilla's
> > cache or expand the size of the quota for each user to deal with the added
> > space requirements.
> >
> > If you are concerned about disk usage from caches, you can always create
> > a script that removes the cache(s) when the user logs out.
>
> That's not the right thing.. that way you loose caching effects around
> logins even when there's plenty of space.
>
> There's quite a lot of data -- at least on my systems -- that can be
> removed with "only" loss of performance...
>
> 1) browser caches
>
> 2) package lists, downloaded packages
>
> 3) object files
>
> heck, if you know you have reliable network connection 4), you could
> even mark stuff like /usr/bin/mozilla elastic, and re-install it from
> the network when it is needed... Doing anything more complex than 1)
> requires extensive changes all around the kernel and userland, and
> you'd probably not call that system unix any more.
>
> I'm not saying that "elastic" feature should go into 2.6 or 2.8 or
> whatever, but it still seems interesting to me.
Couldn't most of this be done in userspace with xattrs and a "elastic
quota" daemon? Mark such files as elastic with an xattr, and when space
is needed for user N, the daemon comes along and deletes the marked
files. You could even make the deamon semi-smart and take things such
as filesize, least recently used files, etc into account.
Or maybe I am missing something... wouldn't be the first time.
josh
Hi all,
>> > 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.
Also this is applicable to mailboxes - automize the marking of old mails of
the mailing list as elastic, whenever the threshold is reached, you might
either want to put those mails as compressed archive or simply delete it.
This has two advantages:
- No email bounces for the reason of 'mailbox full' and
- Optimized utlization of the mailbox
Yes, this can be done using scripts too, but what if you are to use other
users' space that they are not using? Of course script cannot do that! You
need to have some FS support or a libquota hack.
>>
>> How does Mozilla (or any process) react when its files are deleted from
>> under it? Would the file remain until all the open processes close the
>> file or would it just "disappear"?
>
>Of course, if mozilla marked them "elastic" it should better be
>prepared for they disappearance. I'd disappear them with simple
>unlink(), so they'd physically survive as long as someone held them
>open.
>
>> Would it delete entire directories or
>> just some of the files? How does it choose? (First up against the
delete
>> when the drive space fills...)
>
>Probably just some of the files... Or you could delete directory, too,
>if it was marked "elastic". What to delete first... probably file with
>oldest access time? Or random file, with chance of being selected
>proportional to file size?
One can either even mark the whole directory as elastic. When it comes to
taking action, I think I'II opt for random deletion of the files for not
being unfair to any particular user.
AG
Amit Gud wrote:
>Hi all,
>
>
>
>>>>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.
>>>>
>>>>
>
>Also this is applicable to mailboxes - automize the marking of old mails of
>the mailing list as elastic, whenever the threshold is reached, you might
>either want to put those mails as compressed archive or simply delete it.
>This has two advantages:
> - No email bounces for the reason of 'mailbox full' and
> - Optimized utlization of the mailbox
>
>Yes, this can be done using scripts too, but what if you are to use other
>users' space that they are not using? Of course script cannot do that! You
>need to have some FS support or a libquota hack.
>
>
What you're suggesting is not something that could be controlled by the
file system because there are far too many methods for storing email.
Consider, for instance, if all email messages are stored in a single
database file. Unless you include parsing code for all email storage
methods, there's no possible way for your design to work. As you should
be able to see, this "feature" should be implemented in the email server
code; *not* the file system.
Personally, I would rather not use this feature, at all; but, I'm also
entitled to leaving the elastic bit turned off on all my messages.
Sean
"Amit Gud" <[email protected]> said:
[...]
> Also this is applicable to mailboxes - automize the marking of old mails of
> the mailing list as elastic, whenever the threshold is reached, you might
> either want to put those mails as compressed archive or simply delete it.
Right. And which to do is a policy decision, left to the individual owner
of this particular file or collection of files. Democracy at work ;-)
> This has two advantages:
> - No email bounces for the reason of 'mailbox full' and
It will fill up eventually...
> - Optimized utlization of the mailbox
> Yes, this can be done using scripts too,
Having the system fool around with my mail because you get too much junk
and can't be bothered to delete it is what I'd consider an hostile act.
Case closed, anyway. It belongs in the kernel only if there is no
reasonable way to do it in userspace.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
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.
Two pieces of kernel support are needed:
1) some way to indicate "this file is elastic" (okay perhaps xattrs
can do this already)
and either
2a) file selection/deletion in kernel
or
2b) assume that disk does not fill up faster than 1GB/sec, allways
keep 1GB free, make "deleting" daemon poll each second [ugly,
unreliable]
or
2c) just before returning -ENOSPC, synchronously tell userspace to
free space, and retry the operation.
BTW 2c) would be also usefull for undelete. Unfortunately 2c looks
very complex, too; it might be easier to do 2a than 2c.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Fri, 2004-06-25 at 09:25, Pavel Machek wrote:
> 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.
>
> Two pieces of kernel support are needed:
>
> 1) some way to indicate "this file is elastic" (okay perhaps xattrs
> can do this already)
>
> and either
>
> 2a) file selection/deletion in kernel
>
> or
>
> 2b) assume that disk does not fill up faster than 1GB/sec, allways
> keep 1GB free, make "deleting" daemon poll each second [ugly,
> unreliable]
>
> or
>
> 2c) just before returning -ENOSPC, synchronously tell userspace to
> free space, and retry the operation.
>
> BTW 2c) would be also usefull for undelete. Unfortunately 2c looks
> very complex, too; it might be easier to do 2a than 2c.
Why does the kernel have to get involved with file deletion?
All it needs is to run at sufficient privs.
If you are overflowing drives that easily, it is time to buy a bigger
drive. It is not the time to start deleting stuff at random. Data is
usually put on a drive for a reason. Having a human decide what to
delete is *much* better than letting some automated process do it in
background.
This sounds like a hack to get around a badly designed system with too
few resources.
Windows has an option to delete files "that are not needed". It tends
to delete things that you wanted, but had not thought about in a while.
This really strikes me as a bad idea. It has lots of "special" things
that programs will have to deal with for this particular case.
This makes things much more complex in userspace for a problem that
needs to be dealt with in meatspace.
--
"Ye have locked yerselves up in cages of fear--and, behold, do ye now
complain that ye lack FREEDOM!"
- Lord Omar in THE EPISTLE TO THE PARANOIDS Chaper 1 Verse 1
Pavel Machek <[email protected]> said:
> 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...
> 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.
> or
> 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.
> or
> 2c) just before returning -ENOSPC, synchronously tell userspace to
> free space, and retry the operation.
Ugly.
> 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
disposal. I love the Unix way exactly because I decide what to do (no "I
know better than you what to do", "you dumb user aren't supposed to do
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...))
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
I have a much simpler idea that both implements the EQFS and doesn't
touch the kernel.
Each user is given a quota which applies to their home directory. (This
quota is not elastic and if everyone met their quota, everything would
fit.) In addition, there is another directory or file system (could be
on the same disk or even the same partition) to which their quota
doesn't apply AT ALL. Let's call this "scratch" space.
Periodically, a daemon checks the disk usage, and whenever the disk
usage approaches, say, 90%, its starts deleting the oldest files from
the scratch space until its gets below the watermark.
So anything in "/scratch/$USER/" is free to be deleted by the daemon.
BTW, they did something similar to this when I was in college (I
graduated in 1996), although they deleted from /scratch manually.
Alan wrote:
>On Fri, 2004-06-25 at 09:25, Pavel Machek wrote:
>
>
>>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.
>>
>>Two pieces of kernel support are needed:
>>
>>1) some way to indicate "this file is elastic" (okay perhaps xattrs
>>can do this already)
>>
>>and either
>>
>>2a) file selection/deletion in kernel
>>
>>or
>>
>>2b) assume that disk does not fill up faster than 1GB/sec, allways
>>keep 1GB free, make "deleting" daemon poll each second [ugly,
>>unreliable]
>>
>>or
>>
>>2c) just before returning -ENOSPC, synchronously tell userspace to
>>free space, and retry the operation.
>>
>>BTW 2c) would be also usefull for undelete. Unfortunately 2c looks
>>very complex, too; it might be easier to do 2a than 2c.
>>
>>
>
>Why does the kernel have to get involved with file deletion?
>
>
>
Involvement of the kernel depends on how we are treating the elastic
files:
- when files are made elastic, are we increasing the user's quota?
if so kernel becomes neccessary for if
- elastic file is deleted: decrement the user's quota
- elastic file is chowned: do the needfull (decrement previous
owners and increment new owners quota)
- when files are made elastic, we are just not accounting the file
size for the user's quota. In this case I dont see any involvement of
the kernel, but will need some other hacks.
>All it needs is to run at sufficient privs.
>
>If you are overflowing drives that easily, it is time to buy a bigger
>drive. It is not the time to start deleting stuff at random. Data is
>usually put on a drive for a reason. Having a human decide what to
>delete is *much* better than letting some automated process do it in
>background.
>
>
>
Admin assigns quotas to the user with using some case studies, like he
won't be allocating 500 Mb for a C language course students. We are
trying to harness some user behavior here. I wish I had some Gartner or
Forrestor figures to show you that how often _all_ the users use up
their 100% quota at any given point of time. I'm assuming that this
*does* happen very rarely and I also assume that my assumption is very
close to correct. The point is their is some 'free' space available for
the users who use up all their quotas. Of course this free space is
likely to be someday fall short for the over-spilling users, but then
its time to increase quotas of all the users, and its then admin's duty
to look at this. Perhaps this could become a good indication for the
admin for increasing the quota of all the users.
>This sounds like a hack to get around a badly designed system with too
>few resources.
>
>Windows has an option to delete files "that are not needed". It tends
>to delete things that you wanted, but had not thought about in a while.
>
>This really strikes me as a bad idea. It has lots of "special" things
>that programs will have to deal with for this particular case.
>This makes things much more complex in userspace for a problem that
>needs to be dealt with in meatspace.
>
>
>
I do believe that this system can be done in userspace, but it has its
own flaws then. Suppose theres a daemon, call it eqfsd. It forks parent
listens a char device, child watches the disk space usage. A kernel
module reports the file deletes, chowns to the char device, parent does
the needfull. Child 'periodically' checks that the threshold is not
reached. Here what can be done is suppose a user can transfer data with
say 5 Mbps speed to his account....then we can easily get the minimum
time required to fill up the remaining free space. Child sleeps for this
much time minus some value for safety. i.e. child sleeps for: ( (D -
Ui) / 5 ) - safety_value seconds.
I'm sure this gotta be slow and *will* slow down the system, so I still
insist that this should be in kspace.
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.
AG
Horst von Brand wrote:
>Pavel Machek <[email protected]> said:
>
>
>>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 a file or directory? If its file, daemon has to do the ugly
insertion deletion of the file enteries. If its a directory, daemon has
to do the updating of the files in case of mv, plus follow the links for
unlink, chown if we are storing the files as symlinks and we will be
wasting the inodes.
Just think of the load on the system if we run a daemon, which sleeps
for a time depending on the data transfer rate and the amount of free
space left, and if the free space left is very close to the margin...
the system might even freeze. The primary intention of taking
filesystems into kernel is the speed and the security that we get,
otherwise we do have userspace filesystems!
What we need is an application-transparent system which of course should
be plugable within a system and which also shouldn't hamper the system
throughput in a major way.
I really don't see user space implementation in the picture.
AG
Timothy Miller wrote:
>
> I have a much simpler idea that both implements the EQFS and doesn't
> touch the kernel.
>
> Each user is given a quota which applies to their home directory.
> (This quota is not elastic and if everyone met their quota, everything
> would fit.) In addition, there is another directory or file system
> (could be on the same disk or even the same partition) to which their
> quota doesn't apply AT ALL. Let's call this "scratch" space.
>
I guess the system should be more transparent to the users and their
applications. Here its not convenient to generate .o files or caches in
/scratch/$USER/ .
AG
Horst von Brand wrote:
> Pavel Machek <[email protected]> said:
>
>
>> 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 a file or directory? If its file, daemon has to do the ugly
insertion deletion of the file enteries. If its a directory, daemon has
to do the updating of the files in case of mv, plus follow the links for
unlink, chown if we are storing the files as symlinks and we will be
wasting the inodes.
Just think of the load on the system if we run a daemon, which sleeps
for a time depending on the data transfer rate and the amount of free
space left, and if the free space left is very close to the margin...
the system might even freeze. The primary intention of taking
filesystems into kernel is the speed and the security that we get,
otherwise we do have userspace filesystems!
What we need is an application-transparent system which of course should
be plugable within a system and which also shouldn't hamper the system
throughput in a major way.
I really don't see user space implementation in the picture.
AG
On Fri, 25 June 2004 07:07:48 -0500, Josh Boyer wrote:
>
> Couldn't most of this be done in userspace with xattrs and a "elastic
> quota" daemon? Mark such files as elastic with an xattr, and when space
> is needed for user N, the daemon comes along and deletes the marked
> files. You could even make the deamon semi-smart and take things such
> as filesize, least recently used files, etc into account.
>
> Or maybe I am missing something...
"when space is needed" is hard to detect for the daemon.
J?rn
--
To my face you have the audacity to advise me to become a thief - the worst
kind of thief that is conceivable, a thief of spiritual things, a thief of
ideas! It is insufferable, intolerable!
-- M. Binet in Scarabouche
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.
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. I also tend to believe that the exact
time/date that the file was removed could conceivably occur six months
prior to that Monday morning, without the users knowledge. Now the
burden will again be placed on to system administrators. This time, to
locate and recover the lost file(s) by sorting through months of
archives. Personally, I prefer setting quota's on an individual bases,
to finding a needle in a haystack
In my mind, you either have a quota or you don't; there's no in between.
Sean
Hi!
> >This sounds like a hack to get around a badly designed system with too
> I do believe that this system can be done in userspace, but it has its
> own flaws then. Suppose theres a daemon, call it eqfsd. It forks parent
> listens a char device, child watches the disk space usage. A kernel
> module reports the file deletes, chowns to the char device, parent does
> the needfull. Child 'periodically' checks that the threshold is not
> reached. Here what can be done is suppose a user can transfer data with
> say 5 Mbps speed to his account....then we can easily get the
> minimum
I believe I can write data at 1GB/sec at common hardware (~RAM
speed). You'll either need a *lot* of free space, or very fast
polling, and it will still break when the daemon is swapped out, when
scheduler decides writer is more important etc.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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!
Not to argue whether its a good idea but, one use for this would be
undeleting. rm becomes a set EQFS bit. You keep all your old files that
way until space is really needed and then they get reclaimed. You might
not want that to count against your quota.
On Fri, 2004-06-25 at 13:22, 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.
>
> 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. I also tend to believe that the exact
> time/date that the file was removed could conceivably occur six months
> prior to that Monday morning, without the users knowledge. Now the
> burden will again be placed on to system administrators. This time, to
> locate and recover the lost file(s) by sorting through months of
> archives. Personally, I prefer setting quota's on an individual bases,
> to finding a needle in a haystack
>
> In my mind, you either have a quota or you don't; there's no in between.
>
> Sean
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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?
> 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.
AG
On Sat, Jun 26, 2004 at 12:14:50AM +0530, Amit Gud wrote:
> Timothy Miller wrote:
>
> >
> >I have a much simpler idea that both implements the EQFS and doesn't
> >touch the kernel.
> >
> >Each user is given a quota which applies to their home directory.
> >(This quota is not elastic and if everyone met their quota, everything
> >would fit.) In addition, there is another directory or file system
> >(could be on the same disk or even the same partition) to which their
> >quota doesn't apply AT ALL. Let's call this "scratch" space.
> >
> I guess the system should be more transparent to the users and their
> applications. Here its not convenient to generate .o files or caches in
> /scratch/$USER/ .
>
Symlinks. I mozilla stores a cache in .mozilla/something,
then make .mozilla/something a symlink to /scratch/user/.mozilla/something
In a big installation, a script can do this for all users
as well as similiar tricks for other caching apps.
Helge Hafting
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 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?
Sean
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
Stephen Wille Padnos wrote:
> 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.
You're right; I did missunderstand one of the main points. I was under
the impression that I could take whatever I needed, as long as it were
available. This does change my view on the subject, somewhat.
Thanks for clearing that up,
Sean
On Friday 25 June 2004 10:52, Lionel Bouton wrote:
> Pavel Machek wrote the following on 06/25/2004 12:03 AM :
> >Of course, if mozilla marked them "elastic" it should better be
> >prepared for they disappearance. I'd disappear them with simple
> >unlink(), so they'd physically survive as long as someone held them
> >open.
>
> Doesn't work reliably : the deletion is done in order to reclaim space
> that is needed now. You may want to retry unlinking files until you
> reach the free space needed, but this is clearly a receipe for famine :
> process can wait on writes an unspecified amount of time.
This could be solved like OOM by killing all related processes.
<<V13>>
V13 wrote the following on 06/27/2004 08:18 PM :
>On Friday 25 June 2004 10:52, Lionel Bouton wrote:
>
>
>>Pavel Machek wrote the following on 06/25/2004 12:03 AM :
>>
>>
>>>Of course, if mozilla marked them "elastic" it should better be
>>>prepared for they disappearance. I'd disappear them with simple
>>>unlink(), so they'd physically survive as long as someone held them
>>>open.
>>>
>>>
>>Doesn't work reliably : the deletion is done in order to reclaim space
>>that is needed now. You may want to retry unlinking files until you
>>reach the free space needed, but this is clearly a receipe for famine :
>>process can wait on writes an unspecified amount of time.
>>
>>
>
>This could be solved like OOM by killing all related processes.
>
>
I don't want to see mozilla shut down because it was filling a cache
file during a big download...
Note :
In practice I don't see it as a real problem with good-manered
applications : as we are speaking of mutualised storage space,
statistically the system should find files to remove unless it is
burried under open filedescriptors for elastic files. But this is not
really robust : a very simple DoS against this is to allocate all the
available storage space in elastic files and maintain the
filedescriptors open.
To continue on the "kill process" subject : I think making aware the
process of the problem is much more sane. I'd really like mozilla to
tell me : "Sorry, my download cannot continue, the system removed the
download file in order to free some disk space".
IMHO one way to make this work *reliably* is to allow the fs to remove
the files from disk directly and not simply unlink them and wait for the
last fd to be closed. The fs must then return an EBADF (I don't know if
a new error code tailored for this case is affordable) for subsequent
read/writes and applications using elastic files must be written to
gracefully recover from this.
It seems much more logical to me to make applications aware of the
exotic nature of elastic files and handle the associated behavior.
Conceptually elastic files seem different enough from regular files that
you would want to handle them separately at the application level. In
fact I believe elastic files should be created by elastic aware
applications and not by adventurous users/admins. For example I'd really
prefer mozilla to choose to create elastic files when configured to do
so and not have an admin make a chattr on the cache directory...
On Saturday 26 June 2004 07:16 pm, Stephen Wille Padnos wrote:
> 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.
-snip-
> 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
It looks (to my untrained eyes) like a user-driven caching "algorithm", where
I can keep these KDE tarballs around next to the kernel sources, and a few
shiny new slackware ISOs, and all are of course replaceable, but I mark them
elastic or put them in /scratch/... to recover my space at the cost of an
increased probability that I'll have to download some of them again. I like
it.
--
Rob Couto [[email protected]]
computer safety tip: use only a non-conducting, static-free hammer.
--
Lionel Bouton wrote:
> V13 wrote the following on 06/27/2004 08:18 PM :
>
> >On Friday 25 June 2004 10:52, Lionel Bouton wrote:
> >
> >
> >>Pavel Machek wrote the following on 06/25/2004 12:03 AM :
> >>
> >>
> >>>Of course, if mozilla marked them "elastic" it should better be
> >>>prepared for they disappearance. I'd disappear them with simple
> >>>unlink(), so they'd physically survive as long as someone held them
> >>>open.
> >>>
> >>>
> >>Doesn't work reliably : the deletion is done in order to reclaim space
> >>that is needed now. You may want to retry unlinking files until you
> >>reach the free space needed, but this is clearly a receipe for famine :
> >>process can wait on writes an unspecified amount of time.
> >>
> >>
> >
> >This could be solved like OOM by killing all related processes.
> >
> >
>
> I don't want to see mozilla shut down because it was filling a cache
> file during a big download...
>
> Note :
> In practice I don't see it as a real problem with good-manered
> applications : as we are speaking of mutualised storage space,
> statistically the system should find files to remove unless it is
> burried under open filedescriptors for elastic files. But this is not
> really robust : a very simple DoS against this is to allocate all the
> available storage space in elastic files and maintain the
> filedescriptors open.
>
> To continue on the "kill process" subject : I think making aware the
> process of the problem is much more sane. I'd really like mozilla to
> tell me : "Sorry, my download cannot continue, the system removed the
> download file in order to free some disk space".
> IMHO one way to make this work *reliably* is to allow the fs to remove
> the files from disk directly and not simply unlink them and wait for the
> last fd to be closed. The fs must then return an EBADF (I don't know if
> a new error code tailored for this case is affordable) for subsequent
> read/writes and applications using elastic files must be written to
> gracefully recover from this.
> It seems much more logical to me to make applications aware of the
> exotic nature of elastic files and handle the associated behavior.
> Conceptually elastic files seem different enough from regular files that
> you would want to handle them separately at the application level. In
> fact I believe elastic files should be created by elastic aware
> applications and not by adventurous users/admins. For example I'd really
> prefer mozilla to choose to create elastic files when configured to do
> so and not have an admin make a chattr on the cache directory...
>
Right. For the moment its safe enough to allow only elastic-aware
applications to
create the elastic files. A new error code would ceratinly be helpful here.
Here we do take away user control of stating which files he don't want in
case the threshold is reached, but this would definately cause other
applications work smoothly provided there are no commonly shared files. But
once most applications become elastic-aware, he can comfortably do so. Also
we can even have a flag, something like -elas, in gcc for creating object
files as elastic.
AG
On 25-Jun-04, Timothy Miller wrote:
>
> I have a much simpler idea that both implements the EQFS and doesn't
> touch the kernel.
>
> Each user is given a quota which applies to their home directory. (This
> quota is not elastic and if everyone met their quota, everything would
> fit.) In addition, there is another directory or file system (could be
> on the same disk or even the same partition) to which their quota
> doesn't apply AT ALL. Let's call this "scratch" space.
>
> Periodically, a daemon checks the disk usage, and whenever the disk
> usage approaches, say, 90%, its starts deleting the oldest files from
> the scratch space until its gets below the watermark.
>
> So anything in "/scratch/$USER/" is free to be deleted by the daemon.
>
> BTW, they did something similar to this when I was in college (I
> graduated in 1996), although they deleted from /scratch manually.
An easy setup for this is to put /home on a different filesystem than
/tmp, use quota on /home but leave quota off for /tmp. Then most Unix
systems can easily be configured to clean up /tmp periodically, and also
the user is easily aware of the nature of files in /tmp (i.e. they are
"elastic" in some sense).
My university was (and still is) using this setup on many servers.
--
Olaf Dabrunz (od/odabrunz), SUSE Linux AG, Nürnberg