Path: utzoo!utgpu!water!watmath!mks!alex
From: alex@mks.UUCP (Alex White)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MKS: multi-volume backups.
Message-ID: <391@mks.UUCP>
Date: 8 Feb 88 15:32:14 GMT
References: <195@tijc02.UUCP> <2962@cup.portal.com>
Organization: Mortice Kern Systems, Waterloo, Ont.
Lines: 54

In article <2962@cup.portal.com>, Isaac_K_Rabinovitch@cup.portal.com writes:
> 
> rdo031@tijc02.UUCP (Rick Odle           ) writes:
> ->MKS gives an example in their manual of doing something like this:
> ->
> ->	find /dir -type f | cpio -oc | dd of=a:
> ->
> ->the -oa keeps the modification time of the original file.  The real problem
> ->lies in the fact that dd will not write a large archive to a multi-diskette
> ->volume.  Also there is no compression of the files involved.  
I always hate to refer to things that are going to be coming out later
[NO - the release date hasn't yet been set], but the new version of cpio
has several enhancements:
1) builtin compression.  Using the -z flag `cpio -ocz' is entirely equivalent
to on unix typing `cpio -oc | compress -b 14' [and `cpio -icz' to
`uncompress | cpio -ic']
2) multi-volume stuff.  Actually, its sort of in there now, though not
as nicely.  If output is to a file, then when cpio gets an out of disk space
error, it just asks for another filename.  Change floppies, put another one
in, and give it a new filename [or, since you changed floppies, the same
name]. Ditto, on input if end of file is reached and cpio's trailer hasn't
been read, it asks for a new filename. Now this of course doesn't help
the pipe to dd if you want to go to a raw floppy, but...
3) raw-disk driver.  I don't know if this will ever see the light of day
because DOS makes these things so hard - it appears to go out of its way
to make sure you can't do reasonable things - but I do have a driver in
my config.sys file, and now can back up via
	find /dir -type f | cpio -ocvz >/dev/fdaq

> Your examples express my worries.  The pipeline works efficiently under
> Unix, because the three programs are all executing "at once" (working in
> lock-step, taking advantage of each others' pauses), with the pipeline
> keeping the three processes in sync.  By contrast, MS-DOS implements
> this pipeline as three sequential program loads, with nothing happening
> when the program waits on I/O, and two humungous temp files being created.
> Time consuming, and prodigal of disk space.
Absolutely - this pipeline is not something one would want to do on DOS.
However, most pipelines are fully as efficient on DOS as Unix - assuming
that you don't want to watch the data coming out the far end while its
going in.
Consider though, how A | B is implemented:
Unix:
	A runs, data copied to kernel,
	context switch to B
	data copy from kernel to B
	context switch back to A,
	...
Dos:
	A runs to completion: data copied to RAM disk
	Switch to B: data copied from RAM disk to B
Now, with the assumption of a RAM disk, and one which is large enough
for your largest pipe [I have about a meg] can anyone think of any reason
that the dos method should be slower in terms of time-to-complete?
[Certainly not in terms of time-to-first-output].