public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lionel Bouton <Lionel.Bouton@inet6.fr>
To: V13 <v13@priest.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Elastic Quota File System (EQFS)
Date: Sun, 27 Jun 2004 21:42:23 +0200	[thread overview]
Message-ID: <40DF231F.6090608@inet6.fr> (raw)
In-Reply-To: <200406272118.23510.v13@priest.com>

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...


  reply	other threads:[~2004-06-27 19:42 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-23 15:53 Elastic Quota File System (EQFS) Amit Gud
2004-06-23 17:53 ` Mark Watts
     [not found]   ` <1088016048.15211.10.camel@sage.kitchen>
2004-06-24  9:28     ` Amit Gud
2004-06-24 11:50       ` Olaf Dabrunz
2004-06-24 14:04         ` Sam Elstob
2004-06-24 13:51           ` Olaf Dabrunz
2004-06-24 14:17         ` Pavel Machek
2004-06-24 19:58           ` Fao, Sean
2004-06-24 20:28             ` Timothy Miller
2004-06-24 20:30             ` Timothy Miller
2004-06-24 21:30             ` Pavel Machek
2004-06-24 20:51               ` alan
2004-06-24 22:03                 ` Pavel Machek
2004-06-24 23:07                   ` alan
2004-06-25  0:15                     ` Pavel Machek
2004-06-25 11:57                       ` Fao, Sean
2004-06-25 12:07                       ` Josh Boyer
2004-06-25 19:34                         ` Jörn Engel
2004-06-25 17:37                       ` Timothy Miller
2004-06-25 18:44                         ` Amit Gud
2004-06-26 12:00                           ` Helge Hafting
2004-06-25 19:09                         ` Amit Gud
2004-06-30 13:02                         ` Olaf Dabrunz
2004-06-25  7:52                   ` Lionel Bouton
2004-06-27 18:18                     ` V13
2004-06-27 19:42                       ` Lionel Bouton [this message]
2004-06-28 15:34                         ` Amit Gud
2004-06-25  3:04       ` Bernd Eckenfels
2004-06-23 20:37 ` Rik van Riel
  -- strict thread matches above, loose matches on Subject: below --
2004-06-25 14:02 Amit Gud
2004-06-25 14:23 ` Fao, Sean
2004-06-25 14:44 ` Horst von Brand
2004-06-25 16:25   ` Pavel Machek
2004-06-25 16:44     ` Alan
2004-06-25 17:35       ` Amit Gud
2004-06-25 20:22         ` Fao, Sean
2004-06-25 23:50           ` Kevin Fox
2004-06-26  4:03           ` Amit Gud
2004-06-26 21:36             ` Fao, Sean
2004-06-26 23:16               ` Stephen Wille Padnos
2004-06-27  1:44                 ` Fao, Sean
2004-06-28 13:43                 ` Rob Couto
2004-06-25 21:36         ` Pavel Machek
2004-06-25 17:07     ` Horst von Brand
2004-06-25 18:44       ` Amit Gud
2004-06-25 21:44       ` Pavel Machek
2004-06-23 15:48 gud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40DF231F.6090608@inet6.fr \
    --to=lionel.bouton@inet6.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=v13@priest.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox