Centos CI issues
by Frank Filz
See https://review.gerrithub.io/#/c/ffilz/nfs-ganesha/+/409213/
Centos CI seems to be having an issue with Gluster packages.
This also shows an issue with several Centos CI tests sharing a Gerrit ID -
one test set verify -1 but then the next test passed and overrode the verify
-1 with a verify +1.
I'm guessing the testing has no way to track a cumulative state, so it would
work better to have separate IDs.
Frank
6 years
Announce Push of V2.7-dev.10
by Frank Filz
Branch next
Tag:V2.7-dev.10
Release Highlights
* NFSv4.1: Use slot mutex to serialize use of the slot
* Limit max file size to INT64_MAX
* NLM: Adjust lock length if lock end would be > max file size
* NFSv4: If lock offset plus length > max file size return NFS4ERR_BAD_RANGE
* Man page clarifications
* Several gtest fixes
* CMake - Let ntirpc find it's modules
* Don't unregister netconfig_udpv6 unless registered with rpcbind
* Fixes to allow VFS subfsals to control referrals
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
9cf00dc Frank S. Filz V2.7-dev.10
f59840a Sriram Patil Fixes to allow VFS subfsals to control referrals
573dfb8 Malahal Naineni Don't unregister netconfig_udpv6 unless registered
with rpcbind
0baccf3 Daniel Gryniewicz CMake - Let ntirpc find it's modules
3c82074 Girjesh Rajoria gtest: Added export_perms to the gtests
633243c Girjesh Rajoria gtest/test_read2_latency: read2 latency
microbenchmark
770a630 Girjesh Rajoria gtest/CMakeLists: libraries for commit2
132ede3 Girjesh Rajoria gtest/test_write2_latency: write2 latency
microbenchmark
c591cc4 Frank S. Filz Man page clarifications
4314748 Frank S. Filz NFSv4: If lock offset plus length > max file size
return NFS4ERR_BAD_RANGE
c811fe9 Frank S. Filz NLM: Adjust lock length if lock end would be > max
file size
9565ce7 Frank S. Filz Limit max file size to INT64_MAX
282f7df Frank S. Filz NFSv4.1: Use slot mutex to serialize use of the slot
6 years
Re: ACL cache
by Sagar M D
Denial,
I went through "mdcache_refresh_attrs" which is called to invalidate the
cache based on mtime.
change mode wont change the mtime, it changes only ctime alone.
Do you think, ctime also to be considered for invalidating the cache?
On local ext3 filesystem, i see chmod changes only ctime.
[root@ tmp]# stat 1.txt
File: ‘1.txt’
Size: 0 Blocks: 0 IO Block: 4096 regular empty
file
Device: fd00h/64768d Inode: 845864 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2018-04-24 14:45:18.869208038 +0530
Modify: 2018-04-24 14:45:18.869208038 +0530
*Change: 2018-04-24 14:45:18.869208038 +0530*
Birth: -
[root@ tmp]# chmod 777 1.txt
[root@ tmp]# stat 1.txt
File: ‘1.txt’
Size: 0 Blocks: 0 IO Block: 4096 regular empty
file
Device: fd00h/64768d Inode: 845864 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2018-04-24 14:45:18.869208038 +0530
Modify: 2018-04-24 14:45:18.869208038 +0530
*Change: 2018-04-26 12:29:45.446766807 +0530*
Birth: -
Thanks,
Sagar.
On Wed, Apr 25, 2018 at 7:03 PM, Daniel Gryniewicz <dang(a)redhat.com> wrote:
> I was assuming you meant the mode changed behind Ganesha's back. If the
> only changes are coming through Ganesha, it shouldn't be a problem, right?
> In mdcache_setattr2(), it checks to see if ACL, MODE, OWNER, or GROUP
> changes, and if so, refreshed the ACLs along with the other attributes.
>
> Daniel
>
> On 04/25/2018 09:24 AM, Sagar M D wrote:
>
>> Hi Daniel,
>>
>> chmod call also will go through ganesha to fsal. So ganesha should
>> invalidate the old cache and update itself with new attribute in the cache
>> right ?
>> On what basis ganesha will invalidate the cache, only through up call
>> from fsal and time based?
>>
>> Thanks,
>> Sagar.
>>
>> On Wed, Apr 25, 2018 at 5:33 PM, Daniel Gryniewicz <dang(a)redhat.com
>> <mailto:dang@redhat.com>> wrote:
>>
>> Hi, Sagar.
>>
>> Not just ACLs are cached, mode bits are as well. So the correct
>> solution is to send an UP-call when the mode bits change to
>> invalidate the cache on that object.
>>
>> Daniel
>>
>>
>> On 04/25/2018 06:46 AM, Sagar M D wrote:
>>
>> Hi,
>>
>> Can we disable ACL cache through some configuration?
>>
>> We are converting mode bits to ACE in our FSAL. Due to ACL
>> caching, ganesha is not calling into fsal to get the ACL.
>> So if there is any mode change after ganesha caches initial ACL,
>> Ganesha just sends the old mode bits ACL from the cache itself.
>>
>> These are the operation performed.
>> [root@ ACL_Demo]# touch 20.txt
>>
>> [root@ ACL_Demo]# nfs4_getfacl 20.txt
>> A::OWNER@:rwatTnNcC
>> A::GROUP@:rtnc
>> A::EVERYONE@:rtnc
>>
>> [root@ ACL_Demo]# chmod 777 20.txt
>> [root@ ACL_Demo]# nfs4_getfacl 20.txt
>> A::OWNER@:rwatTnNcC
>> A::GROUP@:rtnc
>> A::EVERYONE@:rtnc
>>
>> Any help would be appreciated here.
>>
>> Thanks,
>> Sagar.
>>
>>
>> _______________________________________________
>> Devel mailing list -- devel(a)lists.nfs-ganesha.org
>> <mailto:devel@lists.nfs-ganesha.org>
>> To unsubscribe send an email to
>> devel-leave(a)lists.nfs-ganesha.org
>> <mailto:devel-leave@lists.nfs-ganesha.org>
>>
>> _______________________________________________
>> Devel mailing list -- devel(a)lists.nfs-ganesha.org
>> <mailto:devel@lists.nfs-ganesha.org>
>> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>> <mailto:devel-leave@lists.nfs-ganesha.org>
>>
>>
>>
>
6 years
ACL cache
by Sagar M D
Hi,
Can we disable ACL cache through some configuration?
We are converting mode bits to ACE in our FSAL. Due to ACL caching, ganesha
is not calling into fsal to get the ACL.
So if there is any mode change after ganesha caches initial ACL, Ganesha
just sends the old mode bits ACL from the cache itself.
These are the operation performed.
[root@ ACL_Demo]# touch 20.txt
[root@ ACL_Demo]# nfs4_getfacl 20.txt
A::OWNER@:rwatTnNcC
A::GROUP@:rtnc
A::EVERYONE@:rtnc
[root@ ACL_Demo]# chmod 777 20.txt
[root@ ACL_Demo]# nfs4_getfacl 20.txt
A::OWNER@:rwatTnNcC
A::GROUP@:rtnc
A::EVERYONE@:rtnc
Any help would be appreciated here.
Thanks,
Sagar.
6 years
Byte range lock length and overflow
by Frank Filz
In NFS v4 and NLM, the lock length type is uint64_t. In many of our
supported filesystems, lock length is defined as off_t or off64_t which are
signed quantities.
The Windows NFS v3 client at least has demonstrated issuing a lock length of
UINT64_MAX.
FSAL_GPFS returns an error if lock length is greater than LONG_MAX.
FSAL_GLUSTER and FSAL_VFS stuff the value into an off64_t, and then
complains about lock length being less than zero.
I'm not sure about the other FSALs.
Returning an error ends up making Windows applications not work which is not
ideal.
I think it might be best if inside the FSAL, we just quietly reduce lock
length to a valid value, though I don't know if that should be:
0 - indicating end of file
INT64_MAX - largest possible length
INT64_MAX - offset - so end of lock doesn't exceed INT64_MAX
Does anyone have any thoughts?
Frank
6 years
Announce Push of V2.7-dev.9a
by Frank Filz
Branch next
Tag: V2.7-dev.9a
Release Highlights
* A variety of cmake cleanups and fixes
* gtest/test_commit2_latency: commit2 latency microbenchmark
* GTest - Some fixes to close test
* Move expire_time_attr into export_perms
* Log when open_fd_count goes negative
* Fixing an issue in write stats
* fix 'Bind_Addr' config option documentation
* python: prepare for python2->python3, explicit python2 in shebang
* nfsd: handle rpcbind registration errors more gracefully
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
42d06db Frank S. Filz V2.7-dev.9
6f44a08 Jeff Layton nfsd: handle rpcbind registration errors more gracefully
d143d96 Kaleb S. KEITHLEY python: prepare for python2->python3, explicit
python2 in shebang
6c8fe19 Ramana Raja fix 'Bind_Addr' config option documentation
369afc9 Girjesh Rajoria gtest/test_commit2_latency: commit2 latency
microbenchmark
a46f85d Sriram Patil Fixing an issue in write stats
12b1148 Daniel Gryniewicz CMake cleanups
887819a Daniel Gryniewicz CMake - make goption work with cache
fc5e13e Daniel Gryniewicz Log when open_fd_count goes negative
b1f54a8 Daniel Gryniewicz Add debug option to turn off front ends
70d97d6 Daniel Gryniewicz GTest - Some fixes to close test
e76c786 Frank S. Filz Move expire_time_attr into export_perms
dd47274 Frank S. Filz Remove unsused _N_XATTRD from CMakeLists.txt
6 years
Announce Push of V2.7-dev.9
by Frank Filz
Branch next
Tag:V2.7-dev.9
Release Highlights
* A variety of cmake cleanups and fixes
* gtest/test_commit2_latency: commit2 latency microbenchmark
* GTest - Some fixes to close test
* Move expire_time_attr into export_perms
* Log when open_fd_count goes negative
* Fixing an issue in write stats
* fix 'Bind_Addr' config option documentation
* python: prepare for python2->python3, explicit python2 in shebang
* nfsd: handle rpcbind registration errors more gracefully
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
6f44a08 Jeff Layton nfsd: handle rpcbind registration errors more gracefully
d143d96 Kaleb S. KEITHLEY python: prepare for python2->python3, explicit
python2 in shebang
6c8fe19 Ramana Raja fix 'Bind_Addr' config option documentation
369afc9 Girjesh Rajoria gtest/test_commit2_latency: commit2 latency
microbenchmark
a46f85d Sriram Patil Fixing an issue in write stats
12b1148 Daniel Gryniewicz CMake cleanups
887819a Daniel Gryniewicz CMake - make goption work with cache
fc5e13e Daniel Gryniewicz Log when open_fd_count goes negative
b1f54a8 Daniel Gryniewicz Add debug option to turn off front ends
70d97d6 Daniel Gryniewicz GTest - Some fixes to close test
e76c786 Frank S. Filz Move expire_time_attr into export_perms
dd47274 Frank S. Filz Remove unsused _N_XATTRD from CMakeLists.txt
6 years, 1 month
[Devel] Re: [Nfs-ganesha-devel] Is the mailing list dead? Or just quiet?
by Kaleb S. KEITHLEY
A few subscription requests are trickling in that I have approved.
There was one post to -support by a non-subscriber that was held for
moderation that I let through. (about ERR 20: Auth Rejected
Credentials). I haven't seen anyone reply to that though. It was cc-ed
to the sourceforge -support list too.
The gerrit mails still seem to only be going to the sourceforge -devel list.
On 04/20/2018 05:10 AM, Daniel Gryniewicz wrote:
> This list has been deprecated. Please subscribe to the new devel list at
> lists.nfs-ganesha.org.
> All I've gotten this week has been gerrit notifications. Is everyone
> just quiet? Or did something happen to the list (or my subscription)?
>
> Daniel
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
6 years, 1 month
[Devel] Testing
by Frank Filz
Testing to see who has subscribed so far.
Frank
6 years, 1 month