On Mon, 2009-08-31 at 18:03 -0400, J. Bruce Fields wrote: > On Mon, Aug 31, 2009 at 03:16:11PM -0400, Trond Myklebust wrote: > > From: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > > > > The fact that the filesystem is present does _not_ imply that the > > fs_locations attribute should be marked as "unsupported". > > Yes, but the fact that the filesystem is present also does not imply > that exp->ex_fslocs.locations is NULL. So I'm confused by your > characterization of the existing code. > > If you want to do this, you probably also want to turn off the previous > exfslocs.locations check in the same function. Otherwise we claim > support for the attribute but then never actually return it. ...why is that a problem? Clients that conform to RFC3530 are perfectly capable of dealing with that case. The point is that if you say "I don't support this attribute", then the client will _never_ be allowed to check it. IOW: if you later decide to add replica information to the /etc/exports file, then none of the existing clients will be able to check that information. Furthermore, you are basically promising the clients that you will never return NFS4ERR_MOVED on that volume, since you're telling them that you don't support fs_locations on it. So you can't ever migrate it... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
