Subject: Re: rough SA patch (works on SMP)
To: Nathan J. Williams <email@example.com>
From: Wolfgang Solfrank <firstname.lastname@example.org>
Date: 06/24/2003 19:41:03
> 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?
ws@TooLs.DE Wolfgang Solfrank, TooLs GmbH +49-228-985800