Subject: Re: README: changes to config, to support dump device configuration
To: maximum entropy <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/14/1997 16:15:20
Uh, why not do diskless-workstation dumps via TFTP? Why use NFS if
all you want is to copy bits from main memory into a known file on
disk? If TFTP is good enough for booting, it should be good enough for
a kernel dump, too; and it avoids all the NFS and krpc code. (it
could even use special-case UDP and IP code, if that turns out to be
>>In one sense, it's not. In another, the way dumps are done to disk typically
>>involves a relatively short code path... put NFS in there, and suddenly you
>>involve the krpc code, udp code, ip code, ethernet drivers (which may play
>>tricky mbuf games), buffer cache, etc.
>I see your point here...but it still can be done. To use a really
>lousy example, ULTRIX supports dumping over the network.
Oh, it's not *that* lousy. Ultrix is arguably the finest 4.2BSD
system there ever was. But even with all the enhancements, it's still
a pre-4.3BSD system, and it shows.
Back to the 1990s: my guess is that supporting dumps from diskless
workstations is *required* by a commerical vendor who offers customer
support. Suppose the standard diagnostic procedure for kernel crashes is to
have the customer is to send a kernel config file (or kernel) and
savecore output to the support centre.
You pretty much *have* to support kernel coredumps from diskless
workstations, or you can't offer support to support diskless
workstations at all. This is of course much easier with block-IO
abstractions like ND, RVD, VAXcluster I/O, or TFTP, than with a
filesystem-abstraction like NFS.
If we decide to support dumps from diskless workstations, can we
at least _consider_ dumping via TFTP as an alternative to NFS?