Elastic Quota File System (EQFS)
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
Quoted 9 lines
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?
Quoted 3 lines · Amit Gud
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 ?
Signature · 3 lines
"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
Quoted 7 lines · Mark Watts
Quoted 6 lines
Quoted 6 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
using it, let others use it, but on the guarantee that you get it back
when
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 29 lines
Quoted 1 line
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
Quoted 31 lines · Amit Gud
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.
Quoted 9 lines
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.
Quoted 84 lines
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,
AGQuoted 7 lines · Mark Watts
Quoted 6 lines
Quoted 6 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
using it, let others use it, but on the guarantee that you get it back
when
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 24 lines
Quoted 1 line
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.
Quoted 5 lines
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/
Signature · 1 line
Olaf Dabrunz (od/odabrunz), SUSE Linux AG, Nürnberg
Quoted 129 lines · Olaf Dabrunz
Quoted 31 lines · Amit Gud
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.Quoted 9 lines
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
Quoted 100 lines
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.
Quoted 92 lines
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,
AGQuoted 8 lines · Mark Watts
Quoted 7 lines
Quoted 7 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
using it, let others use it, but on the guarantee that you get it back
when
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 24 lines
Quoted 1 line
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.
Quoted 5 lines
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
Quoted 6 lines · Sam Elstob
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.
Quoted 12 lines
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.)
Quoted 7 lines
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
Signature · 1 line
Olaf Dabrunz (od/odabrunz), SUSE Linux AG, Nürnberg
Hi!
Quoted 7 lines
Quoted 3 lines
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
Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Quoted 12 lines · Pavel Machek
Quoted 10 lines
Quoted 5 lines
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.
Quoted 4 lines
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
Quoted 29 lines · Sean
Quoted 12 lines · Pavel Machek
Quoted 9 lines
Quoted 4 lines
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.
Quoted 4 lines
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/
Quoted 1 line · Sean
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!
Quoted 19 lines
Quoted 14 lines
Quoted 7 lines
Quoted 7 lines
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 correspondingQuoted 5 lines
- 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.
Quoted 5 lines
Actually, think .o or mozilla cache files... You don't need them, but if you have them,
things are faster.
Quoted 8 lines
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
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Quoted 8 lines · Pavel Machek
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 ~).
Quoted 5 lines
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!
Quoted 8 lines
Quoted 8 lines
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".
Quoted 7 lines
Quoted 3 lines
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.
Quoted 3 lines
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
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Quoted 14 lines · Pavel Machek
Hi!
Quoted 12 lines
Quoted 11 lines
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.
Quoted 8 lines
Quoted 3 lines
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.)
Quoted 10 lines
Quoted 3 lines
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!
Quoted 10 lines
Quoted 4 lines
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.
Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
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
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Quoted 7 lines · 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
Signature · 2 lines
eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Pavel Machek wrote the following on 06/25/2004 12:03 AM :
Quoted 7 lines
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.
Signature · 7 lines
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
Quoted 17 lines
Quoted 6 lines
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
Quoted 9 lines
3) object files
heck, if you know you have reliable network connection 4), you could even mark stuff like
/usr/bin/mozillaelastic, 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
Quoted 19 lines · Pavel Machek
Quoted 6 lines
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
Quoted 8 lines
heck, if you know you have reliable network connection 4), you could even mark stuff like
/usr/bin/mozillaelastic, 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
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.
Quoted 5 lines · Timothy Miller
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
Quoted 26 lines · Horst von Brand
Quoted 10 lines · Pavel Machek
Hi!
Quoted 3 lines
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...
Quoted 5 lines
Two pieces of kernel support are needed:
1) some way to indicate "this file is elastic" (okay perhaps xattrs can do this already)
Quoted 8 lines
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
Quoted 8 lines · Josh Boyer
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
Signature · 4 lines
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
Quoted 12 lines · Amit Gud
Quoted 10 lines · Timothy Miller
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.
Quoted 4 lines
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
Quoted 10 lines · Lionel Bouton
Pavel Machek wrote the following on 06/25/2004 12:03 AM :
Quoted 4 lines
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 :
Quoted 12 lines · Lionel Bouton
Quoted 11 lines
Pavel Machek wrote the following on 06/25/2004 12:03 AM :
Quoted 6 lines
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.
Quoted 10 lines
Quoted 6 lines
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...
Quoted 47 lines · Lionel Bouton
V13 wrote the following on 06/27/2004 08:18 PM :
Quoted 12 lines · Lionel Bouton
Quoted 11 lines
Pavel Machek wrote the following on 06/25/2004 12:03 AM :
Quoted 6 lines
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.Quoted 10 lines
Quoted 6 lines
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.
Quoted 9 lines
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
Quoted 10 lines · Timothy Miller
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.
Quoted 8 lines
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.
Signature · 1 line
Olaf Dabrunz (od/odabrunz), SUSE Linux AG, Nürnberg