[wplug] PXE Netboot

[Tom Rhodes]

On Fri, 05 Dec 2008 07:44:51 -0500
"Brian A. Seklecki" <bseklecki at collaborativefusion.com> wrote:

> On Sun, 2008-11-02 at 17:16 -0500, Roland Hess wrote:
> > For a personal project, I'm trying to learn netbooting via PXE (using 
> > DHCP on the server side, not BOOTP). My eventual goal is to be able to 
> > netboot machines into a live (non-HD installed) Ubuntu server 
> 
> It takes about a 5 minutes to setup on FreeBSD, less on NetBSD where the
> bootloader isn't insane.
> 
> You flick on TFTP daemon, DHCP, and NFS server.
> 
> Hardware gets a DHCP address lease; Lease tells it where to TFTP its
> stage 1 & stage 2 x86 boot loader.  PXE code on the NIC TFTPs it down
> and hands it to the BIOS for boot.
> 
> Stage 1 loader has sufficient NFS capabilities to mount the root file
> system and load the kernel.
> 
> After that, you've got the 30-year old debate on how to split a POSIX
> file system across network and local resources.

Not that it splits across the network and local resources, but
I'd like to try this with ZFS should the NFS support mature a
bit more.

> 
> I recommend killing yourself and/or avoiding UDP NFS on gigabit
> Ethernet.

This is a good idea, UDP NFS on GigE has a higher risk of data
corruption IIRC.  From the RFC:

   The side effects caused by performing a duplicate
   non-idempotent request can be destructive (for example, a
   truncate operation causing lost writes). The combination of a
   stateless design with the common choice of an unreliable
   network transport (UDP) implies the possibility of
   destructive replays of non-idempotent requests. Though to be
   more accurate, it is the inherent stateless design of the NFS
   version 3 protocol on top of an unreliable RPC mechanism that
   yields the possibility of destructive replays of
   non-idempotent requests, since even in an implementation of
   the NFS version 3 protocol over a reliable
   connection-oriented transport, a connection break with
   automatic reestablishment requires duplicate request
   processing (the client will retransmit the request, and the
   server needs to deal with a potential duplicate
   non-idempotent request).

In plain English: with higher data rates, the odds of a dropped packet
has a higher chance of silent data corruption.  NFSv3 is stateless,
thus, it doesn't perform its own checking of command order etc,
so layering it on top of an unreliable transport == bad idea

NFSv4 doesn't allow layering on UDP at all :)

-- 
Tom Rhodes