Date: Wed, 20 May 2009 17:36:06 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Juli Mallett <jmallett@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, Rick Macklem <rmacklem@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r192463 - head/sys/fs/nfsserver Message-ID: <Pine.GSO.4.63.0905201730140.20113@muncher.cs.uoguelph.ca> In-Reply-To: <eaa228be0905201229m2fcd024t58c29206776e0a30@mail.gmail.com> References: <200905201858.n4KIw7Fc040619@svn.freebsd.org> <eaa228be0905201229m2fcd024t58c29206776e0a30@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 May 2009, Juli Mallett wrote: > When client ids have been run out of, does that put something into a > dangerous state (insecure or crash-prone)? Isn't it better to let the > administrator make the decision of when to reboot the machine? > Well, first off, this will "never" happen in practice. the clientid generator is a 32bit unsigned, which means it will wrap around in 13.6 years if there is an average rate of 10 new clientids/sec. Since a new clientid only typically happens once per mount (some clients might even do less), it seems highly unlikely that an "average rate of 10/sec" could happen even on the busiest server with clients doing short term mounts. (There was talk of a client inside a web browser, but I don't know that it has ever been written.) When the 32bit # wraps around, rebooting would be the only solution, since re-issuing the same clientid is verboten by the RFC. If it was something I will see happen in my lifetime, I would be more concerned about it. The only reason I put it in is so no one can argue I can violate the RFC. Have fun, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0905201730140.20113>