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 requirement. 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 richard.ell...@richardelling.com +1-760-896-4422
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
