From: Robert Thurlow (Robert.Thurlow@eng.sun.com)
Date: 05/31/02-11:59:51 AM Z
Date: Fri, 31 May 2002 10:59:51 -0600 (MDT) From: Robert Thurlow <Robert.Thurlow@eng.sun.com> Subject: Re: Replication/Migration conference call minutes, 5/29 Message-ID: <Roam.SIMC.2.0.6.1022864391.5734.thurlow@jurassic.eng> > If you're moving something from a source to a target, then wouldn't it > make more sense for the target to do reads and gettattrs and such, instead > of the source doing writes and setattrs? I think this is worse because the source has much better awareness of what is to be transferred. If the target has to walk the file tree to discover what needs to be pulled, that seems to introduce unnecessary round-trips and traffic. Also remember that we need a way to send only changes for a replica update; we'd like to send only parts of file data and metadata that have changed, and only the source can know that. I'm convinced we need a "push" protocol for this reason. > What's wrong with the following as a migration protocol: Given a source > machine with a directory tree that we want to move to a target machine: > > 1. The target machine mounts the directory tree from > the source. > 2. The target machine then exports this same tree. At > this point, the target is just another client to > the source machine, but can also serve the same > tree to other clients. > 3. The target machine tells the source that it wants > to take over. > 4. The source machine then starts sending > NFS4ERR_MOVED in response to any further requests, > except for requests coming from the target, which > the source continues to process normally. > So now the clients of the source have all become clients of the target, > and the target is a client of the source. The target could just do the > equivalent of a "cp -a" at this point to move the data from the source, > probably dropping requests from the clients in the meantime, or it could > choose to only make the requests to the source that it needs to make in > order to service incoming client requests. If it was smart, it would > probably do some combination of the two. I'd summarize this as "arrange the mappings and then let page faults take care of moving the data." You absolutely need to take action to move all the data, or else you can never know when the source can go offline? Also, your clients could pay quite a penalty in performance when two network hops need to happen; what's the advantage of not having the source field their requests until the transfer is done? > This doesn't solve the problem of transferring state, but > no-one knows how to solve that problem anyway right now. As a first > attempt, we've said we're content with migrations that look to clients > like server reboots. Opinions vary, but state transfer is still of interest to some as a way to get the best transparency. > Maybe there are obvious problems with this. But if someone could point > out those problems, maybe that would help me understand better why we > need an entirely separate protocol to do migration, and what features > such a protocol must have if we do need one. I hope the above helps. Another motivation is the hope that we can do this more efficiently than big honking compound ops; that will obviously need to be proven. Rob T
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:47 AM Z CST