Re: [Nfs-ganesha-devel] seek2 useless ?

2017-02-16 Thread Frank Filz 
On 02/16/2017 02:41 AM, LUCAS Patrice wrote:
> Hi Frank,
>
>
> After a quick search, it seems that seek2 is never called and
> implemented only by the two stackable fsals, mdcache and nullfs.
>
>
> Can you confirm that it is useless to implement seek2 in the
> support_ex version of FSAL_PROXY ?
>
>
> Best regards,
>
Seek2 is there for NFS v4.2, it probably won't get much implementation
until we have more 4.2 support.


Frank


--
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove unneeded NULL pointer check

2017-02-16 Thread GerritHub 
>From Malahal :

Malahal has uploaded a new change for review. ( 
https://review.gerrithub.io/349147


Change subject: Remove unneeded NULL pointer check
..

Remove unneeded NULL pointer check

Fixes coverity CID 156270

Change-Id: I44bd5c6b844a18190950eb45ed9fbb7df4d6e298
Signed-off-by: Malahal Naineni 
---
M src/FSAL/FSAL_GPFS/export.c
1 file changed, 1 insertion(+), 2 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/47/349147/1
-- 
To view, visit https://review.gerrithub.io/349147
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I44bd5c6b844a18190950eb45ed9fbb7df4d6e298
Gerrit-Change-Number: 349147
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Malahal 
--
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] Dirent invalidation on up call

2017-02-16 Thread Frank Filz 
> On 02/16/2017 12:21 PM, Frank Filz wrote:
> >> mdcache_readdir() checks !mdc_dircache_trusted(), and calls
> >> mdcache_dirent_populate(), which calls mdcache_dirent_invalidate_all().
> >
> > Ah, ok. Good.
> >
> > Path will be slightly re-worked with chunking, but will do that.
> >
> > I wonder if we should just always mark contents un-trusted and then in
> > readdir, lookup, and create, dump the entries?
> >
> > Frank
> 
> I don't have a strong opinion about that...  It's this way because that's
how
> cache_inode did it, not because I chose to do it that way.
> 
> Upcalls have the desired property, I think, of not introducing extra
latency
> into a thread owned by another system.  I guess it might be good to remove
> that latency from unlink/rename/etc.?  But on the other hand, it frees
> memory now that may never be freed otherwise, which can be beneficial...

Hmm, that might be a good point. With chunking at least we won't have the
memory sitting forever since LRU will dispose of chunks that haven't been
used in a while, combined with limit on number of chunks in play.

Frank


---
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Allow FSAL to determine if a user is superuser

2017-02-16 Thread GerritHub 
>From Daniel Gryniewicz :

Daniel Gryniewicz has uploaded a new change for review. ( 
https://review.gerrithub.io/349135


Change subject: Allow FSAL to determine if a user is superuser
..

Allow FSAL to determine if a user is superuser

Some systems have an alternative superuser, not just UID 0.  Allow this
by adding a is_superuser() method to the FSAL export that is passed
credentials and determines if the user is superuser.   By default, check
the UID against 0.

Change-Id: Id236ad29e044504bb277b7a114fbca3217093896
Signed-off-by: Daniel Gryniewicz 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_export.c
M src/FSAL/Stackable_FSALs/FSAL_NULL/export.c
M src/FSAL/access_check.c
M src/FSAL/default_methods.c
M src/FSAL/fsal_helper.c
M src/include/fsal_api.h
M src/support/nfs_creds.c
7 files changed, 86 insertions(+), 9 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/35/349135/1
-- 
To view, visit https://review.gerrithub.io/349135
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Id236ad29e044504bb277b7a114fbca3217093896
Gerrit-Change-Number: 349135
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Daniel Gryniewicz 
--
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] Dirent invalidation on up call

2017-02-16 Thread Daniel Gryniewicz 
On 02/16/2017 12:21 PM, Frank Filz wrote:
>> mdcache_readdir() checks !mdc_dircache_trusted(), and calls
>> mdcache_dirent_populate(), which calls mdcache_dirent_invalidate_all().
>
> Ah, ok. Good.
>
> Path will be slightly re-worked with chunking, but will do that.
>
> I wonder if we should just always mark contents un-trusted and then in
> readdir, lookup, and create, dump the entries?
>
> Frank

I don't have a strong opinion about that...  It's this way because 
that's how cache_inode did it, not because I chose to do it that way.

Upcalls have the desired property, I think, of not introducing extra 
latency into a thread owned by another system.  I guess it might be good 
to remove that latency from unlink/rename/etc.?  But on the other hand, 
it frees memory now that may never be freed otherwise, which can be 
beneficial...

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

Re: [Nfs-ganesha-devel] Dirent invalidation on up call

2017-02-16 Thread Frank Filz 
> mdcache_readdir() checks !mdc_dircache_trusted(), and calls
> mdcache_dirent_populate(), which calls mdcache_dirent_invalidate_all().

Ah, ok. Good.

Path will be slightly re-worked with chunking, but will do that.

I wonder if we should just always mark contents un-trusted and then in
readdir, lookup, and create, dump the entries?

Frank


---
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] Dirent invalidation on up call

2017-02-16 Thread Daniel Gryniewicz 
mdcache_readdir() checks !mdc_dircache_trusted(), and calls 
mdcache_dirent_populate(), which calls mdcache_dirent_invalidate_all().

Daniel

On 02/16/2017 11:23 AM, Frank Filz wrote:
> Where does that happen? It wasn't clear to me.
>
> Frank
>
> Sent from my iPhone
>
>> On Feb 16, 2017, at 6:31 AM, Daniel Gryniewicz  wrote:
>>
>> The dirents will get cleared out the next time a readdir happens.
>>
>> Daniel
>>
>> On 02/16/2017 12:20 AM, Frank Filz wrote:
 er, oh noes...
>>>
>>> The problem I think I see is that the directory never gets cleaned out in 
>>> this case...
>>>
>>> I get that we may not want to dispose of the dirents on the upcall thread, 
>>> but we should dispose of them the next time we do a lookup or readdir...
>>>
>>> Everything else that invalidates a directory cleans out the dirents inline.
>>>
>>> Frank
>>>
> I'm looking at when dirents are invalidated, and it looks like
> MDCACHE_DIR_POPULATED is cleared on up call, but nothing actually
> cleans out the dirents...
>
> Is this an omission?
>
> Frank
>
>
> ---
> 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
>

 --
 Matt Benjamin
 Red Hat, Inc.
 315 West Huron Street, Suite 140A
 Ann Arbor, Michigan 48103

 http://www.redhat.com/en/technologies/storage

 tel.  734-821-5101
 fax.  734-769-8938
 cel.  734-216-5309
>>>
>>>
>>> ---
>>> 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
>>>
>>
>>
>> --
>> 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
>


--
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] Dirent invalidation on up call

2017-02-16 Thread Frank Filz 
Where does that happen? It wasn't clear to me. 

Frank

Sent from my iPhone

> On Feb 16, 2017, at 6:31 AM, Daniel Gryniewicz  wrote:
> 
> The dirents will get cleared out the next time a readdir happens.
> 
> Daniel
> 
> On 02/16/2017 12:20 AM, Frank Filz wrote:
>>> er, oh noes...
>> 
>> The problem I think I see is that the directory never gets cleaned out in 
>> this case...
>> 
>> I get that we may not want to dispose of the dirents on the upcall thread, 
>> but we should dispose of them the next time we do a lookup or readdir...
>> 
>> Everything else that invalidates a directory cleans out the dirents inline.
>> 
>> Frank
>> 
 I'm looking at when dirents are invalidated, and it looks like
 MDCACHE_DIR_POPULATED is cleared on up call, but nothing actually
 cleans out the dirents...
 
 Is this an omission?
 
 Frank
 
 
 ---
 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
 
>>> 
>>> --
>>> Matt Benjamin
>>> Red Hat, Inc.
>>> 315 West Huron Street, Suite 140A
>>> Ann Arbor, Michigan 48103
>>> 
>>> http://www.redhat.com/en/technologies/storage
>>> 
>>> tel.  734-821-5101
>>> fax.  734-769-8938
>>> cel.  734-216-5309
>> 
>> 
>> ---
>> 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
>> 
> 
> 
> --
> 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


--
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: [commonlib.c] optimize blkid cache handling.

2017-02-16 Thread GerritHub 
>From Swen Schillig :

Swen Schillig has uploaded a new change for review. ( 
https://review.gerrithub.io/349027


Change subject: [commonlib.c] optimize blkid cache handling.
..

[commonlib.c] optimize blkid cache handling.

The blkdid cache was fetched and returned in different
code locations making it difficult to track and handle
its status.

Change-Id: I14f05148d8578f2d1879f0997587ed41e3d42e90
Signed-off-by: Swen Schillig 
---
M src/FSAL/commonlib.c
1 file changed, 31 insertions(+), 45 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/27/349027/1
-- 
To view, visit https://review.gerrithub.io/349027
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I14f05148d8578f2d1879f0997587ed41e3d42e90
Gerrit-Change-Number: 349027
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Swen Schillig 
--
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: FSAL_PROXY (support_ex without state) : pxy_reopen2

2017-02-16 Thread GerritHub 
>From Patrice LUCAS :

Patrice LUCAS has uploaded a new change for review. ( 
https://review.gerrithub.io/349039


Change subject: FSAL_PROXY (support_ex without state) : pxy_reopen2
..

FSAL_PROXY (support_ex without state) : pxy_reopen2

Change-Id: I09861d444bdff6519dfe5e8efd33abc58a126f92
Signed-off-by: Patrice LUCAS 
---
M src/FSAL/FSAL_PROXY/handle.c
1 file changed, 65 insertions(+), 0 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/39/349039/1
-- 
To view, visit https://review.gerrithub.io/349039
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I09861d444bdff6519dfe5e8efd33abc58a126f92
Gerrit-Change-Number: 349039
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Patrice LUCAS 
--
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] Dirent invalidation on up call

2017-02-16 Thread Daniel Gryniewicz 
The dirents will get cleared out the next time a readdir happens.

Daniel

On 02/16/2017 12:20 AM, Frank Filz wrote:
>> er, oh noes...
>
> The problem I think I see is that the directory never gets cleaned out in 
> this case...
>
> I get that we may not want to dispose of the dirents on the upcall thread, 
> but we should dispose of them the next time we do a lookup or readdir...
>
> Everything else that invalidates a directory cleans out the dirents inline.
>
> Frank
>
>>> I'm looking at when dirents are invalidated, and it looks like
>>> MDCACHE_DIR_POPULATED is cleared on up call, but nothing actually
>>> cleans out the dirents...
>>>
>>> Is this an omission?
>>>
>>> Frank
>>>
>>>
>>> ---
>>> 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
>>>
>>
>> --
>> Matt Benjamin
>> Red Hat, Inc.
>> 315 West Huron Street, Suite 140A
>> Ann Arbor, Michigan 48103
>>
>> http://www.redhat.com/en/technologies/storage
>>
>> tel.  734-821-5101
>> fax.  734-769-8938
>> cel.  734-216-5309
>
>
> ---
> 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
>


--
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] reg. FSAL_ACE_PERM_WRITE_DATA check in fsal_check_setattr_perms

2017-02-16 Thread Satya Prakash GS 
Daniel/Frank,

We are using v2.3-stable at the moment. I am yet to go through
stackable fsals to understand your previous comments. Also, we want to
make sure that we aren't hit when we upgrade to v2.4 or latest.

I like the is_super_logic that Frank has proposed, can we have that in
Ganesha. I can own the task and publish the change.

Thanks,
Satya.


On Thu, Feb 16, 2017 at 12:50 AM, Frank Filz  wrote:
>
>> Frank,
>>
>> I have subscribed to the list. Apologies for any inconvenience caused.
>>
>> > This wouldn't actually help since the call to test_access just winds
>> > up in fsal_test_access which isn't going to know about your special super
>> user.
>> > All Ganesha is doing here is not making a test_access call that turns
>> > into an fsal_test_access call that would always fail the permission
>> > check - or actually, I think it might always pass the permission check
>> > for files that don't have an NFS v4 ACL... We would have to change the
>> > test_access API to add permissions to check for in mode tests that are
>> > outside the mode permission checking...
>>
>> > The alternative as a general mechanism is to increase the number of
>> > calls to the underlying filesystem Ganesha makes which is likely to
>> > have a negative impact on other FSAL's performance.
>>
>> Our filesystem doesn't support NFSv4 ACLs. Sorry to prolong this further but
>> just to be clear, we have implemented our own test_access call. In our
>> test_access implementation we have a way to figure out if the user is super
>> user or not. Agree that removing the check would result in a lot of
>> fsal_test_access calls.
>
> What version of Ganesha do you use? 2.4 and later will not ever call your 
> FSAL's test_access because FSAL_MDCACHE always calls fsal_test_access and 
> never calls the underlying FSAL's own test_access.
>
> Maybe what we need is a way for places that are checking for super user to 
> call an FSAL is_super_user(creds) method, which of could would default to 
> returning true only for uid == 0.
>
> Your implementation of course could do whatever you need to do.
>
> Then we just have to get out of the habit of checking for uid == 0 and 
> instead invoke is_super_user(creds)...
>
> Frank
>
>
>
> ---
> 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] how does ganesha limit number of FDs

2017-02-16 Thread Malahal Naineni 
The only way for ganesha to close NFSv3 opens was with this fd count limit
in an earlier release. Now, do we open for each NFSv3 read/write and close
after the read/write?

On Tue, Feb 14, 2017 at 12:51 AM, Frank Filz 
wrote:

> Open fd tracking is an area Ganesha actually needs some additional work,
> however, the tracking in the non-support_ex methods did not limit the
> number of NFS v4 opens in any way, it just was used to manage how many fds
> Ganesha kept open for I/O access to files.
>
>
>
> With support_ex, an fd is associated with each file clients have open (NFS
> v4), and additional fds are (may) be used per file/lock owner pair.
>
>
>
> Ultimately we do need to have a limit on how much state (NFS v4 open,
> NLM_SHARE, locks, delegations, layouts) is active.
>
>
>
> Frank
>
>
>
> *From:* Naresh Babu [mailto:snareshb...@gmail.com]
> *Sent:* Saturday, February 11, 2017 4:21 PM
> *To:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* [Nfs-ganesha-devel] how does ganesha limit number of FDs
>
>
>
> If a particular FSAL implements extended ops like
> open2/write2/read2/commit2, open_fd_count doesn't get tracked. Then, how
> does ganesha limit the number of open FDs? In general, what is the
> rationale behind not tracking open fd count?
>
>
>
> Thanks,
>
> Naresh
>
>
> --
> [image: Avast logo] 
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com 
>
>
> 
> --
> 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
>
>
--
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