public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Amit Gud <gud@eth.net>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: Pavel Machek <pavel@ucw.cz>, alan <alan@clueserver.org>,
	"Fao, Sean" <Sean.Fao@dynextechnologies.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Elastic Quota File System (EQFS)
Date: Sat, 26 Jun 2004 00:14:59 +0530	[thread overview]
Message-ID: <40DC72AB.9020106@eth.net> (raw)
In-Reply-To: <200406251707.i5PH7KOw009004@eeyore.valparaiso.cl>

Horst von Brand wrote:

>Pavel Machek <pavel@ucw.cz> 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


  reply	other threads:[~2004-06-25 18:45 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-25 14:02 Elastic Quota File System (EQFS) 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 [this message]
2004-06-25 21:44       ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2004-06-23 15:53 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
2004-06-28 15:34                         ` Amit Gud
2004-06-25  3:04       ` Bernd Eckenfels
2004-06-23 20:37 ` Rik van Riel
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=40DC72AB.9020106@eth.net \
    --to=gud@eth.net \
    --cc=Sean.Fao@dynextechnologies.com \
    --cc=alan@clueserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=vonbrand@inf.utfsm.cl \
    /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