lkml.org 
[lkml]   [1996]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.2.0 wishlist
Date

> > I still don't think that it should ever be implemented. If you've got
> > home dirs on an almost-full disk (i.e., like 99%), you could conceivably
> > be ``wasting'' maybe 5, 10, even 20% on undeleted files, and the full disk
> > would become a needless annoyance (IMHO :). Does someone
> > have stats on how often & what size files are deleted/created/modeified
> > in a home directory structure? Almost sounds like a computer science
> > master's thesis topic to me.. ;)
>
> A undelete scheme has to be implemented with automatic freeing of
> resources. I mean, if the fs needs space, then it has to do some cleanup.
[...] Agreed. ;)

> Be aware, that
>
> 1-disk space is peanuts these days

Well, not really. I worked at a supercomputer institute a couple of years
ago and we were continually running out of disk space. We could have used
about four times what we had on hand and the reason we couldn't get it was
money.

> 2-This is a feature selectable per user if you wish (or per directory)
> 3-Potentially a mount option could disable it altogether.

See the previous email (discussion with Bryn) regarding implementing this
at the quota level.

> I suspect this could be implement in a libc.so stub also with potentially
> much more flexibility. For example, it would be possible to control this
> behavior
>
> -per user
> -per directory
> -per application
> -per whatever you have in mind
>
> My understanding is that with the new ELF shared libs, it is possible to
> install logically a stub dll between the real libc.so and the apps. This
> dll can intercept different system call (function call in fact) and
> process them differently and ultimatly calling the original.

This would, of course, be the ultimate in flexibility. Per user would
be the finest grain you'd want to go though, I think, since the other two
would require a lot of work to maintain.

--
Bob Glamm | "You can't do a `goto' to a block
Email: glamm@mountains.ee.umn.edu | that has been optimized away.
URL: http://www.cs.umn.edu/~glamm | Darn."
Home: (612)623-9437 Work: (612)625-7876 | - from the perltrap(1) manpage


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.047 / U:2.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site