From: Uresh Vahalia (vahalia@emc.com)
Date: 06/13/99-09:03:13 PM Z
Message-ID: <376462E1.D47FE4B1@emc.com> Date: Sun, 13 Jun 1999 22:03:13 -0400 From: Uresh Vahalia <vahalia@emc.com> Subject: Re: Replication/migration proposal The proposal is more palatable for migration than for replication. The overall problems with getting this info from the server are: 1. Redundancy of information. If a filesystem is available at n sources, each of these n will have to store information about the other n-1. If one thing changes, the change needs to be propagated to all the others. 2. Naming issues in complex networks. Today's servers have multiple IP interfaces, usually with different names for each interface. Each server will have to keep knowledge of all the interfaces of all the servers that provide access to this filesystem. How does the client decide which of these interfaces to choose? The situation is worse if interface names are not the same from the perspective of each client. Not to say this situation is handled cleanly by today's methods, but do we really want to drag this complexity into the NFS protocol? There is a lot of merit to having separate solutions for separate problems rather than adopting a kitchen-sink approach and throwing everything into NFSv4 just because it is needed for file sharing (why not hostname-to-IPaddr translation also, while we are at it?). 3. Even if we look past the above issues, what information must the server return? You suggest hostname:filename. What filename is this? The pathname of the file corresponding to this handle? How will the server know this, once the filesystem is no longer on the server? The pathname of the filesystem root? What does this mean to the client, who may have mounted a subdirectory of the root? The pathname of the directory the client mounted? How does the server know this, regardless of whether the file system is still on the server? Perhaps the only thing that will work is to return just the hostname, expecting the new server to interpret the old handles. Of course, this is why we have volatile filehandles in the first place, but I don't recall there being consensus on whether volatile handles will actually work, especially under such circumstances. Uresh ======================= "Noveck, Dave" wrote: > > > The information the server is providing, according to your > > proposal, is > > What are the locations of this filesystem? > > For replication that's so. For migration, it is what is the > new location for this filesystem. This may not have been known > at the time of mount or the system in question may not have > even have existed at the time of the mount. > > The world of SAN provides a lot of examples. My load is too > heavy on one server and so I transfer a filesystem from one > server to another. Maybe I roll in a new server and transfer > some filesystems to it. In this context, having the > old server tell the clients where the new server is seems like > the simplest thing to do. There are a lot of more complicated > ways to do it and some of them may be better but I don't > understand what is so bad about this simple way of doing > things. > > > Today, this information is available from the automounter > > (even multiple > > locations). What additional information is the protocol > > going to provide? > > Today in many places, people run automounters and some people > don't. They're not part of the nfs protocol. > > I assume that the automounter is going to communicate information > about multiple server locations using mount options (or is there > some other mechanism). If we are not going to bring the automounter > within the scope of the nfs protocol than that (mount options) > is the nfs-protocol-relevant characterization of how this information > gets to the client. > > If people have set things up to use the automounter to manage > this information, and it is propagated appropriately then this is > going to work, at least for the replication case. But I don't > see how the fact that you can do this, means that you shouldn't > be able to get that same information from the server. If you > don't want to set things up to use automounting, then having the > server tell the clients is a simple way to do things. There are > ususally few servers and many clients and so having them get > the information from the server simplifies things. Why not? > > For migration, I don't see how the automounter is going to do > this on already mounted filesystems. > > > The problem with moving the existing mountpoint as opposed to > > unmount/remount is completely orthogonal. If the client > > knows the alternate > > location, its ability to move the mountpoint is independent > > of where it got > > the knowledge. > > Absolutely. However, given that I'm proposing that clients have > that ability, there needs to be some way for the clients to get > that information. For the replication case, this could be done > using mount options, but I don't see how that would work for > migration. I was looking for something that was simple enough > for me to understand and explain didn't involve bringing within > the scope of the protocol a lot of stuff that currently isn't > in it. A hostname:filename or a list thereof works (simply) for > me. > > If someone wants to have a replacement or an additional mechanism > (that works), I'm OK with that. There just needs to be some way > to get the information so that the client can do its thing. >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:13 AM Z CST