On Thu, 11 Mar 1999, Jason Thorpe wrote:

> lfs_cleanerd REALLY should be a kthread now... created dynamically when an
> instance of the file system is mounted... one for each instance...

I'm still not sure about this...it would be *very* useful if the cleaner
could do some other things, not all of which are ideal for in-kernel code:

- When backup time comes around, run the cleaner like mad until the
  filesystem contains lots of free segments, then have it not clean at all
  while backups are being taken.  Or, the cleaner could *be* the backup
  agent, and dump_lfs would just control it.

- Implement site policies regarding "idle periods" when cleaning would be
  more appropriate; or even change cleaning modes for file coalescing, or
  moving seldom-accessed files to the outside of the disk.  The
  determination of idle periods (or even the already existent idle
  thresholds) would have to be done outside of the kernel.

OTOH, it would perhaps be possible for the cleaner to create a control
socket, and be controlled externally by something that knows about
policies.  Then the in-kernel part of the cleaner could be as stupid as it
is now (lfs_{bmapv,markv,segclean,segwait}) or as smart as one would like.  
I'm just not sure which way is better (and my present ignorance regarding
kernel threads doesn't help make it clear one way or the other).

						Konrad Schroder
						perseant@hhhh.org