[Nfs-ganesha-devel] Announce Push of V2.4.0.1

[Frank Filz]

Branch next

Not being sure what naming convention to use for post 2.4.0 tags, I went
with 2.4.0.1.

In a few weeks, after Bakeathon and some stabilization work, we will tag
2.4.1.

And then we will open 2.5

Tag:V2.4.0.1

Release Highlights

* Added missing merge method to GLUSTER, GPFS, and RGW FSALs

* Re-enable owner_skip test_access bypass

* FSAL_GLUSTER cleanup

* Fixed nfs3_mknod

* Build and packaging fixes

* Coverity fix

* enable TCP keepalive in NFS dispatcher with option

* Other minor fixes

Signed-off-by: Frank S. Filz 

Contents:

cf1a3e0 Frank S. Filz V2.4.0.1
b5a84e1 Niels de Vos config: logrotate should not complain about missing
logfiles
7eaa0dd Dominique Martinet NFS dispatcher: add option to enable TCP
keepalive
2b5d4f8 Malahal Naineni Fix MOUNT EXPORT procedure returning reversed
network address string.
d9213d5 Jeff Layton Have posix2fsal_attributes use the posix standard for
time fields by default
83c26f2 Jeff Layton ceph: fix several bugs with the
USE_FSAL_CEPH_LL_LOOKUP_ROOT
8f5e42a Soumya Koduri Add gcc-c++ as Required package
4668188 Daniel Gryniewicz Fix leak - coverity CID 153008
443ada8 Daniel Gryniewicz Re-add owner validation cache optimization
3cf5c8b Kaleb S. KEITHLEY FSAL_GPFS: build errors on Ubuntu xenial
26e7fb5 Marc Eshel FSAL_GPFS: pass NFS client IP to fs.
73443fc Marc Eshel FSAL_GPFS: Add merge method.
eb1601e Frank S. Filz RGW: Add merge method
353f3eb Frank S. Filz GLUSTER: Add merge method
0ded615 Soumya Koduri NLM: Validate state pointer before operating on it
6edd29a Soumya Koduri FSAL_GLUSTER: Find fd only for regular files
cea6d60 Soumya Koduri FSAL_GLUSTER: Cleanup getattrs2()
ab83cd1 Soumya Koduri MKNOD: Invalid check in nfs3_mknod


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Correct way to maintain global fd for FSAL which dont support OFD.

[Tushar Shinde]

On Thu, Sep 29, 2016 at 9:12 PM, Frank Filz  wrote:
>> On Wed, Sep 28, 2016 at 10:03 PM, Frank Filz 
>> wrote:
>> > The same lock owner never has conflicts so one file descriptor per owner
>> per file with OFD locks satisfies all the needs.
>> >
>> > We are planning on separating out the code in SAL that manages the union
>> of all locks. FSALs that have no other way to support lock owners will have 
>> to
>> replicate the lock list inside the FSAL and utilize some code to manage the
>> union of all locks. We may provide an untested helper function in
>> FSAL/commonlib.c.
>> > What is your environment? It sounds like you will be using FSAL_VFS in
>> some way, but don't have OFD locks. Are you using an older Linux or
>> FreeBSD?
>> >
>> I am using vxfs on RHEL-6.7.
>
> Curious why you want to run without MDCACHE.

The upcall cache invalidation framework not in place for this FSAL.
I am interested in knowing performance difference when caching is done
at user level and when it happens only at FS/kernel level. VXFS is
cluster file system, Its important to evaluate how much user mode
cache is contributing to our workloads vs cost of invalidation
framework. With 2.4 separate mdcache plug able layer this may be
easily possible.
Is there any plan to harden NO-MDCACHE code paths moving forward? For
now I will try code with mdcache.

>
>> > I have yet to explore all the implications of no MDCACHE. I believe the
>> existence of vfs_locate_state maintains a reference on the fsal_obj_handle,
>> in which case, you can still keep the global fd in the fsal_obj_handle (and
>> presumably you would still want to do that since stateless I/O requests will
>> come into the FSAL call with no pointer to a state_t and you may not want to
>> take the effort of looking up the vfs_locate_state. On the other hand, I'm
>> not sure how the upper layers get an fsal_obj_handle reference in that
>> case...
>> >
>> > Note that the current vfs_locate_state code is really just a proof of 
>> > concept
>> and only had minimal testing.
>> >
>> My initial try to get it working with similar code as of vfs_locate_state is
>> failed, FSAL with no OFD and no mdcache is facing problem, But it passed
>> couple of runs if global state framework is not used. (offcource leaking fd)
>> also open with O_CREAT|O_RDWR  (AND no O_EXCL) failed, It worked later
>> after commenting
>> +   /*
>> if (createmode != FSAL_NO_CREATE)
>> return fsalstat(ERR_FSAL_INVAL, 0);
>> +   */
>> I am debugging both above, will update findings.
>
> Note that FSAL_VFS will need some work to do byte range locks without OFD 
> locks, and you will have to be very careful to never close any file 
> descriptor from within Ganesha for a file that has range locks (POSIX locks 
> held by a process are dropped when the process closes ANY file descriptor for 
> the file).
> We will also need to move the lock union code into a separate function that 
> can be used by FSALs.
>
>> > Again, I encourage you to share as much as you can. It is hard to give you
>> the best advice with minimal details.
>>
>> Yes, I had started to exploring adding fsal to ganesha code, Trying to
>> understand legal issue etc.
>
> Obviously you will have to consult a lawyer and make your own risk 
> assesement, but the intent of the LGPL licensing is to allow FSALs that 
> interface with proprietary code.

Thank you for helping me on this thread.

Tushar

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: config: logrotate should not complain about missing logfiles

[GerritHub]

>From Niels de Vos :

Niels de Vos has uploaded a new change for review.

  https://review.gerrithub.io/296656

Change subject: config: logrotate should not complain about missing logfiles
..

config: logrotate should not complain about missing logfiles

The NFS-Ganesha packages install logrorate configurations under
/etc/logrotate.d/. In case the service is not enabled and Ganesha has
never been started, there are no logfiles. This causes logrotate to
complain and by default cron will send emails to the root user.

These useless emails can be prevented by marking the logs with the
`missingok` config option.

Change-Id: Idef190964bdd026b70e21ffcd76064ff6148a482
Signed-off-by: Niels de Vos 
---
M src/config_samples/logrotate_fsal_gluster
M src/config_samples/logrotate_ganesha
2 files changed, 2 insertions(+), 0 deletions(-)


  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/56/296656/1
-- 
To view, visit https://review.gerrithub.io/296656
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Idef190964bdd026b70e21ffcd76064ff6148a482
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Niels de Vos 

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel