Re: [Nfs-ganesha-devel] open2 implementations

2016-09-12 Thread Marc Eshel
Ye, FSAL_GPFS could use openat but I want to have control over all the 
calls in GPFS before it calls the VFS. Do you see any problem with the 
code?
Thanks, Marc.



From:   "Frank Filz" 
To: "'nfs-ganesha-devel'" , 
Marc Eshel/Almaden/IBM@IBMUS
Date:   09/12/2016 11:42 AM
Subject:open2 implementations



Marc especially...

I see several open2 implementations seem to be doing a lookup and then an
open2 by handle.

FSAL_CEPH needed to do this because it doesn't have openat to open a file
given a directory handle and a filename within that directory.

FSAL_ VFS can do openat, so it doesn't need to do a lookup...

I'm pretty sure FSAL_GPFS could just use openat...

I'm not sure about FSAL_GLUSTER

I'm guessing FSAL_RGW is in the same boat as FSAL_CEPH.

And FSAL_PROXY and FSAL_ZFS haven't been converted...

Frank



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






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


Re: [Nfs-ganesha-devel] open2 implementations

2016-09-12 Thread Frank Filz
Hmm, another one inside open2 implementations...

Both FSAL_GLUSTER and FSAL_RGW call obj_ops.check_verifier.

FSAL_VFS and FSAL_CEPH use a separate function, check_verifier_stat since
during the retry of an exclusive create, we don't have the object yet, we
have to do a stat to create the object.

FSAL_GPFS uses check_verifier_attrlist since it does it's own extended stat
call that fills in an attrlist.

Oh, FSAL_GLUSTER still has a struct attrlist in glusterfs_handle... That's
probably not right...

It looks like FSAL_RGW should be using check_verifier_stat.

Frank

> -Original Message-
> From: Frank Filz [mailto:ffilz...@mindspring.com]
> Sent: Monday, September 12, 2016 11:42 AM
> To: 'nfs-ganesha-devel' ; 'Marc
> Eshel' 
> Subject: [Nfs-ganesha-devel] open2 implementations
> 
> Marc especially...
> 
> I see several open2 implementations seem to be doing a lookup and then an
> open2 by handle.
> 
> FSAL_CEPH needed to do this because it doesn't have openat to open a file
> given a directory handle and a filename within that directory.
> 
> FSAL_ VFS can do openat, so it doesn't need to do a lookup...
> 
> I'm pretty sure FSAL_GPFS could just use openat...
> 
> I'm not sure about FSAL_GLUSTER
> 
> I'm guessing FSAL_RGW is in the same boat as FSAL_CEPH.
> 
> And FSAL_PROXY and FSAL_ZFS haven't been converted...
> 
> Frank
> 
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> 
>

--
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic patterns at an interface-level. Reveals which users, apps, and
> protocols are consuming the most bandwidth. Provides multi-vendor support
> for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using
> capacity planning reports. http://sdm.link/zohodev2dev
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


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


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


[Nfs-ganesha-devel] open2 implementations

2016-09-12 Thread Frank Filz
Marc especially...

I see several open2 implementations seem to be doing a lookup and then an
open2 by handle.

FSAL_CEPH needed to do this because it doesn't have openat to open a file
given a directory handle and a filename within that directory.

FSAL_ VFS can do openat, so it doesn't need to do a lookup...

I'm pretty sure FSAL_GPFS could just use openat...

I'm not sure about FSAL_GLUSTER

I'm guessing FSAL_RGW is in the same boat as FSAL_CEPH.

And FSAL_PROXY and FSAL_ZFS haven't been converted...

Frank



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


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
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]: MDCACHE - Call the default test_access() directly

2016-09-12 Thread GerritHub
>From Daniel Gryniewicz :

Daniel Gryniewicz has uploaded a new change for review.

  https://review.gerrithub.io/290975

Change subject: MDCACHE - Call the default test_access() directly
..

MDCACHE - Call the default test_access() directly

All FSALs currently use the default test_access() implementation.
However, MDCACHE was calling into the sub-FSAL anyway.  This means that,
when the default test_access() called getattr(), it was uncached,
causing high latency.  Since test_access() is a very common operation,
this was slowing things down a lot.

As a work-around, call the default test_access() directly.  If, at some
future point, some FSAL wants to override test_access(), this will have
to be revisited.

Change-Id: Iba4ab7ece5818a7c752a5fe42e54b78ec6f06467
Signed-off-by: Daniel Gryniewicz 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c
1 file changed, 10 insertions(+), 2 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Iba4ab7ece5818a7c752a5fe42e54b78ec6f06467
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Daniel Gryniewicz 

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel