lkml.org 
[lkml]   [2004]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Elastic Quota File System (EQFS)
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...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.945 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site