Xref: utzoo comp.unix.questions:28240 comp.unix.programmer:901 alt.sys.sun:2558
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!uhccux!munnari.oz.au!metro!cluster!bruce
From: bruce@cs.su.oz (Bruce Janson)
Newsgroups: comp.unix.questions,comp.unix.programmer,alt.sys.sun
Subject: Re: Source for dump/restore/rdump/rrestore?
Message-ID: <1898@cluster.cs.su.oz.au>
Date: 25 Jan 91 13:02:09 GMT
Sender: news@cluster.cs.su.oz.au
Lines: 44

Barry,

In article <1991Jan23.213346.1874@Think.COM> you write:
>..
>status flags).  It accesses the partition through the raw disk device, not
>through the file system system calls, but the NFS protocol only supports
>file system operations.  If you want to be able to dump NFS-mounted file
>systems you can use utilities such as tar (GNU tar includes some options
>that are intended to support its use within a backup system) or other
>3rd-party backup utilities.
>..

    Well, fortunately dump *does* access the raw disk device through the file
system system calls:

	fd = open("/dev/dsk/sd0:, ..);
	..
	lseek(fd, ...);
	read(fd, &buf[0], sizeof(buf));
	..
	close(fd);

-- but I do understand what you are saying...

However, given this, a cute trick is to get the remote NFS server to fake
up the inode fields of the remote device (special) file so that it looks
like a regular file.
That way, the local client code doesn't switch out to do local device read()'s
but passes all the nfs_*() operations over the wire.
As dump only wants to read() the (remote) device this should work well.
You've still got to update the remote /etc/dumpdates file though.

Cheers,
bruce.

Bruce Janson
Basser Department of Computer Science
University of Sydney
Sydney, N.S.W., 2006
AUSTRALIA

Internet:	bruce@cs.su.oz.au
Telephone:	+61-2-692-3272
Fax:		+61-2-692-3838