[nfs-discuss] NFSv4 O_EXCL 6854659
Jeff A. Smith : 6854659 creating file using O_EXCL with linux nfsv4 client results in bogus mtime Thanks Jeff! I look forward to testing this in production in a couple of weeks time when it hits the public IPS depot. cheers, James On 09/10/2009, at 1:40 AM, Jeff A. Smith wrote: > I've coded and unit tested the fix, but there were problems > unrelated to this fix (or even NFS) in getting a clean regression > test run which caused the fix to miss the 125 build. We aren't > willing to push even trivial changes without proper testing. > > I apologize for not keeping you in the loop with this fix, > and I'll be sure to do so going forward. I'm currently setting > up my own testbed to run the regression suites so that I don't > have to wait for the other testbed issues to be diagnosed and > corrected. snv_126 closes tues. 1am central. If I can get a > clean regression run before that time, it will go in.
[nfs-discuss] NFSv4 O_EXCL 6854659
Hi Jeff, On 27/08/2009, at 6:23 AM, Jeff A. Smith wrote: > I'm targeting this fix for build snv_124. It's strange > that this issue hasn't been reported before, because our > NFS4 server has always (mis)behaved this way since NFS4 > first arrived in the first S10 release. Each year we > attend Connectathon and do interop testing with Linux NFS > implementors (and we haven't heard of this before), so it > makes me wonder if a recent Linux NFS client change might > be exposing our misbehavior. I?ve been following this waiting for an update (as it is a showstopper for us) and noted that it had not been fixed in 124 and is still listed as commit to fix 125 but does not appear to have made it in. Are you able to give an update on this CR? cheers, James
[nfs-discuss] NFSv4 O_EXCL 6854659
09, at 11:13 PM, James Lever wrote: > Hi Jeff, > > On 27/08/2009, at 6:23 AM, Jeff A. Smith wrote: > >> I'm targeting this fix for build snv_124. It's strange >> that this issue hasn't been reported before, because our >> NFS4 server has always (mis)behaved this way since NFS4 >> first arrived in the first S10 release. Each year we >> attend Connectathon and do interop testing with Linux NFS >> implementors (and we haven't heard of this before), so it >> makes me wonder if a recent Linux NFS client change might >> be exposing our misbehavior. > > I?ve been following this waiting for an update (as it is a > showstopper for us) and noted that it had not been fixed in 124 and > is still listed as commit to fix 125 but does not appear to have > made it in. > > Are you able to give an update on this CR? > Hi James, I've coded and unit tested the fix, but there were problems unrelated to this fix (or even NFS) in getting a clean regression test run which caused the fix to miss the 125 build. We aren't willing to push even trivial changes without proper testing. I apologize for not keeping you in the loop with this fix, and I'll be sure to do so going forward. I'm currently setting up my own testbed to run the regression suites so that I don't have to wait for the other testbed issues to be diagnosed and corrected. snv_126 closes tues. 1am central. If I can get a clean regression run before that time, it will go in. Jeff
[nfs-discuss] NFSv4 O_EXCL 6854659
Hi Jeff, On 27/08/2009, at 6:23 AM, Jeff A. Smith wrote: > I'm targeting this fix for build snv_124. That's *fantastic* news, thanks! > It's strange that this issue hasn't been reported before, because > our NFS4 server has always (mis)behaved this way since NFS4 first > arrived in the first S10 release. Each year we attend Connectathon > and do interop testing with Linux NFS implementors (and we haven't > heard of this before), so it makes me wonder if a recent Linux NFS > client change might > be exposing our misbehavior. This particular bug has been known about for a few years (google tells me about NFSv4 O_EXCL and corrupt mtime back to 204) and specific reporting of linux/solaris interoperability problems at least 2 years, but nobody probably thought to report it to Sun until recently. I found this one when we root-caused our problem a couple of months ago http://marc.info/?l=linux-nfs&m=118299922500147&w=2 I suspect the reason is that so many people just haven't moved to NFSv4 still considering it *too difficult* (rubbish, but more difficult than NFSv3). With more people using Solaris and OpenSolaris with a ZFS backing datastore they will be really wanting to use NFSv4 mirror-mounts, which somewhat surprisingly are supported natively from linux clients - at least the entire filesystem and all ZFS children show up with a single NFSv4 mount. As this usage rises, especially in enterprise, this type of bug will have more of a chance to be discovered. cheers, James
[nfs-discuss] NFSv4 O_EXCL 6854659
James Lever wrote: > With more people using Solaris and OpenSolaris with a ZFS backing > datastore they will be really wanting to use NFSv4 mirror-mounts, > which somewhat surprisingly are supported natively from linux clients > - at least the entire filesystem and all ZFS children show up with a > single NFSv4 mount. As this usage rises, especially in enterprise, > this type of bug will have more of a chance to be discovered. James, Mirror mounts are client-side only - which simply means that Linux has equivalent capabilities in their client. The NFSv4 protocol is designed to make this easier - i.e., we always have the concept of PUTROOTFH which allows a client to discover the server namespace dynamically. One of the design goals of NFSv4 was to reduce all the traffic to one port to help people configure firewalls. So with PUTROOTFH, your mount command may never result in a MOUNT protocol going otw - it may all be straight NFSv4 traffic. We called it mirror mounts because the client NFSv4 code was *mirroring* what the user did with the mount command. We had some people who had been involved with the automounter and they made some really good decisions about the name space should be able to be traversed dynamically (i.e., if a new mount point is created, you see it near instantly and do not have to wait for the maps to be regenerated) and the capability of the mirror mounts to be automatically harvested if idle. The goal to have 'umount //srv_mnt' automatically recurse to unmount children was also a key design point. But enough gushing, you are right, the combination of the explosion of file systems presented by ZFS and mirror mounts is sweet. Tom
[nfs-discuss] NFSv4 O_EXCL 6854659
Hi James, I'm targeting this fix for build snv_124. It's strange that this issue hasn't been reported before, because our NFS4 server has always (mis)behaved this way since NFS4 first arrived in the first S10 release. Each year we attend Connectathon and do interop testing with Linux NFS implementors (and we haven't heard of this before), so it makes me wonder if a recent Linux NFS client change might be exposing our misbehavior. Jeff On Aug 24, 2009, at 8:49 PM, James Lever wrote: > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6854659 > > Just wondering if anybody knows what's happening with this bug? > It's the only thing keeping us from moving to NFSv4 (which I > desperately need to do to avoid hundreds of lines dozens of servers / > etc/fstab that are quite unmaintainable) > > We're badly affected by this bug due to the way that subversion > creates its lock files by using O_EXCL to create .svn/lock and then > populating .svn/entries with the mtime value which makes doing any > checkouts on an NFSv4 mounted filesystem (from linux) a no-go. > > cheers, > James > ___ > nfs-discuss mailing list > nfs-discuss at opensolaris.org
[nfs-discuss] NFSv4 O_EXCL 6854659
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6854659 Just wondering if anybody knows what's happening with this bug? It's the only thing keeping us from moving to NFSv4 (which I desperately need to do to avoid hundreds of lines dozens of servers /etc/fstab that are quite unmaintainable) We're badly affected by this bug due to the way that subversion creates its lock files by using O_EXCL to create .svn/lock and then populating .svn/entries with the mtime value which makes doing any checkouts on an NFSv4 mounted filesystem (from linux) a no-go. cheers, James
