[Nfs-ganesha-devel] Work in Progress Readdir Chunking Posted

2017-02-22 Thread Frank Filz 
I have a first pass that works and passes pynfs! It isn't quite correct in
that a rename into a directory or a create doesn't invalidate the dirent
cache and thus a readdir might not show the new file.

Unlink and rename out of a directory need not invalidate and should work
properly.

Also left to do is memory management to constrain the total number of
dirents.

The inode cache LRU reclaims the least recently used entry, however that
would cause problems for dirents since to reclaim one, we must hold the
content lock on the containing directory, but we also hold the content lock
on the directory that needs another dirent. If the two directories happen to
be involved in a rename from one directory to another, the order could be
reversed and create a deadlock.

Another option is to have the LRU thread dispose of dirents from the least
recently used directories the same way it disposes of open global file
descriptors. That combined with logic that switched to uncached mode if we
couldn't get a free dirent would allow a reasonable mechanism.

Anyway, I encourage folks who are interested to take a look at the WIP code
and play with it.

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]: Get rid of unused cookie field in struct mdcache_populate_cb...

2017-02-22 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review. ( 
https://review.gerrithub.io/350076


Change subject: Get rid of unused cookie field in struct 
mdcache_populate_cb_state
..

Get rid of unused cookie field in struct mdcache_populate_cb_state

Change-Id: I1fd3ad4679bc7990f6d73bde19f6d9d30ba6f488
Signed-off-by: Frank S. Filz 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
1 file changed, 0 insertions(+), 3 deletions(-)



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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I1fd3ad4679bc7990f6d73bde19f6d9d30ba6f488
Gerrit-Change-Number: 350076
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 
--
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]: Fix FSAL_PSEUDO to return the cookie for the NEXT entry for ...

2017-02-22 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review. ( 
https://review.gerrithub.io/350080


Change subject: Fix FSAL_PSEUDO to return the cookie for the NEXT entry for 
each dirent
..

Fix FSAL_PSEUDO to return the cookie for the NEXT entry for each dirent

The cookie associated with a dirent is the "address" of the NEXT dirent
not the current one. Provide the appropriate cookie now that MDCACHE
will actually be using the FSAL's cookies (this is relevant for
bypassing the dirent cache also).

Change-Id: I215cfe929d67c941bd5dc80e607ebc2f44150c49
Signed-off-by: Frank S. Filz 
---
M src/FSAL/FSAL_PSEUDO/handle.c
1 file changed, 1 insertion(+), 1 deletion(-)



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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I215cfe929d67c941bd5dc80e607ebc2f44150c49
Gerrit-Change-Number: 350080
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 
--
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]: Add glist_last_entry

2017-02-22 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review. ( 
https://review.gerrithub.io/350079


Change subject: Add glist_last_entry
..

Add glist_last_entry

Change-Id: Id206255b2bffd558438981e267f1849bfae69597
Signed-off-by: Frank S. Filz 
---
M src/include/gsh_list.h
1 file changed, 4 insertions(+), 0 deletions(-)



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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Id206255b2bffd558438981e267f1849bfae69597
Gerrit-Change-Number: 350079
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 
--
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]: WIP Add directory chunking for readdir.

2017-02-22 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review. ( 
https://review.gerrithub.io/350081


Change subject: WIP Add directory chunking for readdir.
..

WIP Add directory chunking for readdir.

This still needs directory invalidation on rename and create.

Change-Id: Id4aa058bb5e96c26717234c42a4aa761bd80db67
Signed-off-by: Frank S. Filz 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_avl.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_avl.h
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h
5 files changed, 906 insertions(+), 34 deletions(-)



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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Id4aa058bb5e96c26717234c42a4aa761bd80db67
Gerrit-Change-Number: 350081
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 
--
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] FSAL_PROXY with NVSv4 protocol : no way to truncate ?

2017-02-22 Thread Frank Filz 
> On 02/22/2017 04:53 AM, patrice.lu...@cea.fr wrote:
> > Hi Frank,
> >
> >
> > As I said yesterday during our last concall, I realized that the
> > current FSAL_PROXY use the v4 protocol and not the v4.1.  My previous
> > submitted patchs to implement support_ex assumed FSAL_PROXY was
> using v4.1.
> >
> >
> > Considering differences in v4 and v4.1, I don't see how doing a
> > "truncate" in open2 or in setattr2 in v4 with simply a handle and
> > without a valid state. To set size with a setattr (in v4 as in v4.1),
> > you need a valid state. This state could be the current one in a
> > compound request with an open before the setattr. But, if there is no
> > way to open a file by handle in v4, how can I do this setattr ? Do you
> > have any idea about solving this problem ? How can we successfully
> > truncate a file in FSAL_PROXY following this first "quick and dirty"
> > version of support_ex that ignores states from the background NFS server
> ?
> >
> > I see no other solution than :
> >
> > 1) upgrading this first version of FSAL_PROXY support_ex to one really
> > saving state from the background NFS server,
> >
> > or
> >
> > 2) upgrading FSAL_PROXY protocol from v4 to v4.1.
> >
> >
> 
> My vote is 2.  I don't see a need to support v4.0 at this point, we should
just
> stick to v4.1.

I've had a chat with Bruce Fields and looked at the knfsd code also.

My conclusion based on that discussion is that SETATTR with special stateid
should always be fine.

I think this text from the RFC: 

"A valid stateid SHOULD always be specified. When the file size attribute is
not set, the special anonymous stateid MAY be passed."

Is just confusing us.

The discussion of the special stateids in Section 9.1.4.3 mentions SETATTR
but doesn't say anything about what type of SETATTR.

I really see no reason why a client should be allowed to append to a file
with WRITE and a special stateid but would not be allowed to truncate the
file with the same stateid...

In other words, don't stress about having to open the file.

Once we have full state support, we should pass the state through if
non-special.


---
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] FSAL_PROXY with NVSv4 protocol : no way to truncate ?

2017-02-22 Thread Daniel Gryniewicz 
On 02/22/2017 04:53 AM, patrice.lu...@cea.fr wrote:
> Hi Frank,
>
>
> As I said yesterday during our last concall, I realized that the current
> FSAL_PROXY use the v4 protocol and not the v4.1.  My previous submitted
> patchs to implement support_ex assumed FSAL_PROXY was using v4.1.
>
>
> Considering differences in v4 and v4.1, I don't see how doing a
> "truncate" in open2 or in setattr2 in v4 with simply a handle and
> without a valid state. To set size with a setattr (in v4 as in v4.1),
> you need a valid state. This state could be the current one in a
> compound request with an open before the setattr. But, if there is no
> way to open a file by handle in v4, how can I do this setattr ? Do you
> have any idea about solving this problem ? How can we successfully
> truncate a file in FSAL_PROXY following this first "quick and dirty"
> version of support_ex that ignores states from the background NFS server ?
>
> I see no other solution than :
>
> 1) upgrading this first version of FSAL_PROXY support_ex to one really
> saving state from the background NFS server,
>
> or
>
> 2) upgrading FSAL_PROXY protocol from v4 to v4.1.
>
>

My vote is 2.  I don't see a need to support v4.0 at this point, we 
should just stick to v4.1.

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

[Nfs-ganesha-devel] FSAL_PROXY with NVSv4 protocol : no way to truncate ?

2017-02-22 Thread patrice.lucas 
Hi Frank,


As I said yesterday during our last concall, I realized that the current 
FSAL_PROXY use the v4 protocol and not the v4.1.  My previous submitted 
patchs to implement support_ex assumed FSAL_PROXY was using v4.1.


Considering differences in v4 and v4.1, I don't see how doing a 
"truncate" in open2 or in setattr2 in v4 with simply a handle and 
without a valid state. To set size with a setattr (in v4 as in v4.1), 
you need a valid state. This state could be the current one in a 
compound request with an open before the setattr. But, if there is no 
way to open a file by handle in v4, how can I do this setattr ? Do you 
have any idea about solving this problem ? How can we successfully 
truncate a file in FSAL_PROXY following this first "quick and dirty" 
version of support_ex that ignores states from the background NFS server ?

I see no other solution than :

1) upgrading this first version of FSAL_PROXY support_ex to one really 
saving state from the background NFS server,

or

2) upgrading FSAL_PROXY protocol from v4 to v4.1.


Best regards,

Patrice


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