Hi,

> Remember that SA/LWP is just a particular implementation of
> threads. Don't think about the SA/LWP stuff so much if you're writing
> a program; think about the threads, and the places where there's
> concurrency to be had. The dump(8) program is mostly about sucking
> data off of a filesystem and onto something else, and the kernel's
> own I/O concurrency is sufficent for it, I think. Threads might be
> useful if, for some reason, you wanted a single invocation of the
> dump(8) program to dump multiple filesystems to multiple targets at
> the same time.... but since you can do that with multiple standard
> dump(8) processes, I don't think there's a benefit to that compexity.

Hmm, what he probably was getting at is the "Concurrent dump mods"
implemented in dump(8).  To cite the comment from tape.c:

/*
  * Concurrent dump mods (Caltech) - disk block reading and tape writing
  * are exported to several slave processes.  While one slave writes the
  * tape, the others read disk blocks; they pass control of the tape in
  * a ring via signals. The parent process traverses the file system and
  * sends writeheader()'s and lists of daddr's to the slaves via pipes.
  * The following structure defines the instruction packets sent to slaves.
  */

Maybe this could be simplified with the help of threads, no?

BTW, did anyone think about implementing Extended Copy
(i.e. support for serverless backup) in dump?

Ciao,
Wolfgang
-- 
ws@TooLs.DE	Wolfgang Solfrank, TooLs GmbH	+49-228-985800