Tets results with same posix compliance test suit with 3.2 build

glusterfs-ganesha-3.8.4-18.el7rhgs.x86_64

=====
V3
=====

Test Summary Report
-------------------
/home/new_posix/ntfs-3g-pjd-fstest/tests/chmod/00.t    (Wstat: 0 Tests: 106 Failed: 2)
  Failed tests:  31, 39
/home/new_posix/ntfs-3g-pjd-fstest/tests/ftruncate/00.t (Wstat: 0 Tests: 26 Failed: 1)
  Failed test:  24
/home/new_posix/ntfs-3g-pjd-fstest/tests/mknod/03.t    (Wstat: 0 Tests: 12 Failed: 9)
  Failed tests:  1-3, 5-7, 9-11
Files=210, Tests=2328, 89 wallclock secs ( 1.04 usr  0.26 sys +  9.03 cusr 17.96 csys = 28.29 CPU)
Result: FAIL




====
V4
====

Test Summary Report
-------------------
/home/new_posix/ntfs-3g-pjd-fstest/tests/chmod/00.t    (Wstat: 0 Tests: 106 Failed: 2)
  Failed tests:  31, 39
/home/new_posix/ntfs-3g-pjd-fstest/tests/ftruncate/00.t (Wstat: 0 Tests: 26 Failed: 1)
  Failed test:  24
/home/new_posix/ntfs-3g-pjd-fstest/tests/mknod/03.t    (Wstat: 0 Tests: 12 Failed: 9)
  Failed tests:  1-3, 5-7, 9-11
/home/new_posix/ntfs-3g-pjd-fstest/tests/open/07.t     (Wstat: 0 Tests: 23 Failed: 3)
  Failed tests:  5, 7, 9
Files=210, Tests=2328, 89 wallclock secs ( 1.00 usr  0.27 sys +  8.81 cusr 17.60 csys = 27.68 CPU)
Result: FAIL

Following are failures with new test suite
1.) chmod
2.) mknod
3.) ftruncate
4.) open
5.) link

Here both chomd and mknod are issues with gluster(reproducible with fuse client)

chmod -- is an expected behavior for glusterfs

mknod -- fail to special files with length 4096[PATH_MAX](applicable for directories and files as well). This is because at the backend we need to consider the brick path length as well. So the maximum path length for files inside a glster volume will be 4096-<brick path length>

ftruncate -- it is because of ganesha behavior
Test case : 
1.) create a directory with 0777 permission
2.)a specific user opens file with O_CREAT,O_RDWR and mode bit '0'
3.) then performs ftruncate using that fd

Actually with that opened fd, application can perform truncate. But incase of ganesha after creating(open2) file, it performs an access check in 
open2_by_name()[428 check_open_permission()] which fails with EACCESS since mode bits of that file is 000(----------)




open -- failures are similar to 3.2 only

link -- failing because of stale link to files in previous operation[after debugging does not look like regression from 3.2 can happen even in 3.2]

Testcase
1.) create a fifo file
2.) Trying to create hardlink fails with ESTALE instead of EACCESS

Can happens when hardlink and orginal file are in different subvols.

snippet from test case
-------------------------
expect 0 create ${n0} 0644
expect 0 -- chown ${n0} 65534 -1
|
|
expect EACCES -u 65534 link ${n0} ${n1}
|
|
|
expect 0 unlink ${n0}

expect 0 mkfifo ${n0} 0644
expect 0 -- chown ${n0} 65534 -1
|
|
|
expect EACCES -u 65534 link ${n0} ${n1}

The first hardlink call will fail with EACCESS, but 'T' (link to file) created by that call is not removed. So next hardlink call will with ESTALE because of that issue

So what is the cause and details of the chmod issue? Just want to understand.

For max name lengths, we may need to adjust max path len reported on exports, not sure how all that works. For the compliance tests, this may be a place having a ganesha-gluster type might help so it tries the max path length that can actually work.

I don't quite understand the link issue.

The ftruncate issue we have a fix for right? Or not?

Verified this bug on

# rpm -qa | grep ganesha
nfs-ganesha-2.4.4-15.el7rhgs.x86_64
nfs-ganesha-gluster-2.4.4-15.el7rhgs.x86_64
glusterfs-ganesha-3.8.4-33.el7rhgs.x86_64



Known failures-



====
V3
====
Test Summary Report
-------------------
/home/new_posix/ntfs-3g-pjd-fstest/tests/chmod/00.t    (Wstat: 0 Tests: 106 Failed: 2)
  Failed tests:  31, 39
/home/new_posix/ntfs-3g-pjd-fstest/tests/mknod/03.t    (Wstat: 0 Tests: 12 Failed: 9)
  Failed tests:  1-3, 5-7, 9-11
Files=210, Tests=2328, 91 wallclock secs ( 0.69 usr  0.16 sys + 10.49 cusr 10.42 csys = 21.76 CPU)
Result: FAIL


======
V4
=====

Test Summary Report
-------------------
/home/new_posix/ntfs-3g-pjd-fstest/tests/chmod/00.t    (Wstat: 0 Tests: 106 Failed: 2)
  Failed tests:  31, 39
/home/new_posix/ntfs-3g-pjd-fstest/tests/mknod/03.t    (Wstat: 0 Tests: 12 Failed: 9)
  Failed tests:  1-3, 5-7, 9-11
/home/new_posix/ntfs-3g-pjd-fstest/tests/open/07.t     (Wstat: 0 Tests: 23 Failed: 3)
  Failed tests:  5, 7, 9
Files=210, Tests=2328, 93 wallclock secs ( 0.68 usr  0.16 sys + 10.62 cusr 10.48 csys = 21.94 CPU)
Result: FAIL

Moving this bug to verified state.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2774