On Tue, 2016-09-06 at 12:29 -0400, Oleg Drokin wrote: > On Sep 6, 2016, at 12:00 PM, Jeff Layton wrote: > > > > > > Shrug...feel free to propose a better scheme for generating unique > > ids > > if you can think of one. Unfortunately, there are always cases when > > these mechanisms for getting a persistent+unique id break down. > > > > That's the reason that nfs provides an interface to allow setting a > > uniquifier from userland via module param. > > Fair enough, though I guess module parameter is not really a super > convenient place > for it when you run off nfs-root. > I guess you were not really enticed with the mac address idea too ;) > Which mac address? It's not always a given that the host will initialze them in the same order when you have multiple interfaces, even if the hardware doesn't change out from under you. This is just one of those classic "punt the solution to userland" sort of problems that's just really hard to fix in the kernel in a way that will always work. > Anyway, thank you very much for your help, now I have some better > idea of what's going on and what to try next. No problem. Diagnosing these sorts of problems can be pretty difficult. Note too that earlier versions of the client had a length limitation on this string, which could cause similar problems even when the hostnames are already set if they were very long names and only differed at the end. commit 873e385116b2cc5c7daca8f51881371fadb90970 fixes that problem. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
