On Apr 25, 2012, at 11:00 PM, Nico Williams wrote:

> On Thu, Apr 26, 2012 at 12:10 AM, Richard Elling
> <richard.ell...@gmail.com> wrote:
>> 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
> NFSv3.

Requirements, requirements, requirements... boil the ocean while we're at it? 

> 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
> that direction.

NFSv4 has support for migrating volumes and managing the movement
of file handles. The technique includes filehandle expiry, similar to methods
used in other distributed FSs.

>> 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).

This is already in the v4 spec.

> Although even for v3 it should be possible for servers in a cluster to
> arrange to preserve devids...

We've been doing that for many years.

> Bottom line: live migration needs to be built right into the protocol.

Agree, and volume migration support is already in the NFSv4 spec.

> 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.

Many distributed file systems do this, at the cost of being not quite POSIX-ish.
In the brave new world of storage vmotion, nosql, and distributed object stores,
it is not clear to me that coding to a POSIX file system is a strong 

Perhaps people are so tainted by experiences with v2 and v3 that we can explain
the non-migration to v4 as being due to poor marketing? As a leader of NFS, Sun
had unimpressive marketing.
 -- richard

ZFS Performance and Training

zfs-discuss mailing list

Reply via email to