On Thu, Apr 26, 2012 at 12:10 AM, Richard Elling
> On Apr 25, 2012, at 8:30 PM, Carson Gaspar wrote:
> Reboot requirement is a lame client implementation.
And lame protocol design. You could possibly migrate read-write NFSv3
on the fly by preserving FHs and somehow updating the clients to go to
the new server (with a hiccup in between, no doubt), but only entire
shares at a time -- you could not migrate only part of a volume with
Of course, having migration support in the protocol does not equate to
getting it in the implementation, but it's certainly a good step in
> You are correct, a ZFS send/receive will result in different file handles on
> the receiver, just like
> rsync, tar, ufsdump+ufsrestore, etc.
That's understandable for NFSv2 and v3, but for v4 there's no reason
that an NFSv4 server stack and ZFS could not arrange to preserve FHs
(if, perhaps, at the price of making the v4 FHs rather large).
Although even for v3 it should be possible for servers in a cluster to
arrange to preserve devids...
Bottom line: live migration needs to be built right into the protocol.
For me one of the exciting things about Lustre was/is the idea that
you could just have a single volume where all new data (and metadata)
is distributed evenly as you go. Need more storage? Plug it in,
either to an existing head or via a new head, then flip a switch and
there it is. No need to manage allocation. Migration may still be
needed, both within a cluster and between clusters, but that's much
more manageable when you have a protocol where data locations can be
all over the place in a completely transparent manner.
zfs-discuss mailing list