Re: Elastic Quota File System (EQFS)

[Alan]

On Fri, 2004-06-25 at 09:25, Pavel Machek wrote:
> 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.
> 
> Two pieces of kernel support are needed:
> 
> 1) some way to indicate "this file is elastic" (okay perhaps xattrs
> can do this already)
> 
> and either
> 
> 2a) file selection/deletion in kernel
> 
> or
> 
> 2b) assume that disk does not fill up faster than 1GB/sec, allways
> keep 1GB free, make "deleting" daemon poll each second [ugly,
> unreliable]
> 
> or
> 
> 2c) just before returning -ENOSPC, synchronously tell userspace to
> free space, and retry the operation.
> 
> BTW 2c) would be also usefull for undelete. Unfortunately 2c looks
> very complex, too; it might be easier to do 2a than 2c.

Why does the kernel have to get involved with file deletion?

All it needs is to run at sufficient privs.

If you are overflowing drives that easily, it is time to buy a bigger
drive.  It is not the time to start deleting stuff at random.  Data is
usually put on a drive for a reason.  Having a human decide what to
delete is *much* better than letting some automated process do it in
background.

This sounds like a hack to get around a badly designed system with too
few resources.

Windows has an option to delete files "that are not needed".  It tends
to delete things that you wanted, but had not thought about in a while.

This really strikes me as a bad idea.  It has lots of "special" things
that programs will have to deal with for this particular case. 
This makes things much more complex in userspace for a problem that
needs to be dealt with in meatspace.

-- 
"Ye have locked yerselves up in cages of fear--and, behold, do ye now
complain that ye lack FREEDOM!"
  - Lord Omar in THE EPISTLE TO THE PARANOIDS Chaper 1 Verse 1


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