Difference: OpenSolarisBugs ( vs. 1)

Revision 12012-12-06 - brodbd

Line: 1 to 1
Added:
>
>

List of known OpenSolaris <-> Linux NFSv4 bugs

Because this needs to be documented somewhere... Some of these also affect Nexenta and other Solaris-derived operating systems...be careful out there...

Directory SetGID bit inheritance

If a directory on an NFSv4 share has the setgid (g+s) bit set, new files will correctly adopt the directory's group, but new directories will get the user's default group instead, effectively breaking the inheritance chain.

Fixed in unreleased build snv_135. Appears to be fixed in OpenIndiana 151a2.

Files opened with O_EXCL get bizarrely incorrect mtimes

If a file is created from a Linux client on a Solaris NFSv4 share, using an open() call with O_EXCL set, the file will have the wrong mtime. Often the resulting mtime is far in the future or past (e.g., December 4, 1912.) The main symptom is Subversion checkouts that contain zero-length files end up with corrupt metadata, causing "svn: Bogus date" messages:

~$ svn co svn://lemur.ling.washington.edu/test/zero-length-file-test
A    zero-length-file-test/zero
Checked out revision 23228.

~$ cd zero-length-file-test/

~/zero-length-file-test$ ls -l
total 1
-rw-r--r-- 1 brodbd brodbd 0 Sep 22  1954 zero

~/zero-length-file-test$ svn up
svn: Error at entry 2 in entries file for '.':
svn: Bogus date

This is OpenSolaris bug id #6854659 (unfortunately Oracle has walled off their bug database, so I can't link to it.)

Fixed in unreleased build snv_133. Appears to be fixed in OpenIndiana 151a2.

State recovery errors

These have been hard to pin down. The symptom is the Linux client rapidly logs "kernel: Error: state recovery failed on NFSv4 server xxx.xxx.xxx.xxx with error 2" and generates massive amounts of traffic to the server. It's often accompanied by an nfs thread on the server that shows very high CPU utilization. This can saturate the network and effectively lock out other clients. Occasionally recovery happens spontaneously, but most often it's necessary to reboot either the client or the server to regain normal service.

-- Main.brodbd - 2012-12-06

 
This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
Privacy Statement Terms & Conditions