Re: Elastic Quota File System (EQFS)

[Amit Gud]

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






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