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
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.
ZFS Performance and Training
zfs-discuss mailing list