Re: Elastic Quota File System (EQFS)

[Amit Gud]

Horst von Brand wrote:

> Pavel Machek <pavel@xxxxxx> 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

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