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

[Matt Benjamin]

Hi,

- Original Message -

> 
> Another thought is to look at the nlinks in the directory and decide to
> cache or chunk.

Please do not (invariantly) assume that nlinks is accurate until readdir() :)

Matt

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

--
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] Deepsea support for NFS-Ganesha

[Matt W. Benjamin]

Very nice, thanks folks.

Matt

- "Supriti Singh"  wrote:

> Hello all,
> 
> As I said in the concall this week, at SUSE, we are working on
> salt-based deployment system for ceph, called Deepsea.
> https://github.com/SUSE/DeepSea
> 
> Recently we added support to automatically deploy Ganesha server in
> the ceph cluster. Users can select nodes to
> act as ganesha server. Deepsea takes care of installing nfs-ganesha,
> copying the correct config file and starting the
> service. We support only CephFS and RGW FSALs.
> 
> For CephFS, we don't use admin keyring. Hence, it works only for
> Ganesha v2.5-dev7 or higher.
> 
> Deepsea at the moment can be used only for SUSE distributions.
> 
> Thanks,
> Supriti
> 
> 
> 
> --
> Supriti Singh
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> 
> 
> 
> --
> 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
CohortFS, LLC.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://cohortfs.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309 

--
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] Why FATTR4_ARCHIVE does not have decode method?

[Frank Filz]

Unfortunately we have not had the resources to test Windows clients, let alone 
the NFS v4 client, and no one has been bringing a Windows client to 
Connectathon or Bakeathon for several years now.



I’m not sure what the current state of that client is.



Frank



From: sriram patil [mailto:spsrirampa...@gmail.com]
Sent: Thursday, February 23, 2017 9:36 AM
To: Frank Filz 
Cc: nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] Why FATTR4_ARCHIVE does not have decode method?



Is there any NFSv4 Windows client that works with ganesha?



Thanks,

Sriram



On Thu, Feb 23, 2017 at 10:57 PM, Frank Filz  > wrote:

Hmm, I don’t think Ganesha advertises support for FATTR4_ARCHIVE, so client 
SHOULD NOT be sending it.



Frank



From: sriram patil [mailto:spsrirampa...@gmail.com 
 ]
Sent: Thursday, February 23, 2017 9:22 AM
To: nfs-ganesha-devel@lists.sourceforge.net 

Subject: [Nfs-ganesha-devel] Why FATTR4_ARCHIVE does not have decode method?



Hi,



I was trying to use NFS Ganesha NFSv4 export using a windows client. But this 
windows client is sending FATTR4_ARCHIVE in createattrs as part of OPEN and 
fails to create any file.



decode method for FATTR4_ARCHIVE is not implemented, it returns NOOP. I figured 
that the read-only attributes do not need a decode method, but FATTR4_ARCHIVE 
is a read-write attribute according to RFCs (3530 and 5661). Is there any 
specific reason decode is not implemented for archive?



Also, I am not sure if there is any official windows client for NFSv4, I was 
using the one published by cohortfs. Is there some other windows client with 
which NFS Ganesha works seamlessly?



Thanks,

Sriram



  _


 

This email has been checked for viruses by Avast antivirus software.
www.avast.com 







---
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] Why FATTR4_ARCHIVE does not have decode method?

[sriram patil]

Is there any NFSv4 Windows client that works with ganesha?

Thanks,
Sriram

On Thu, Feb 23, 2017 at 10:57 PM, Frank Filz 
wrote:

> Hmm, I don’t think Ganesha advertises support for FATTR4_ARCHIVE, so
> client SHOULD NOT be sending it.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Thursday, February 23, 2017 9:22 AM
> *To:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* [Nfs-ganesha-devel] Why FATTR4_ARCHIVE does not have decode
> method?
>
>
>
> Hi,
>
>
>
> I was trying to use NFS Ganesha NFSv4 export using a windows client. But
> this windows client is sending FATTR4_ARCHIVE in createattrs as part of
> OPEN and fails to create any file.
>
>
>
> decode method for FATTR4_ARCHIVE is not implemented, it returns NOOP. I
> figured that the read-only attributes do not need a decode method, but
> FATTR4_ARCHIVE is a read-write attribute according to RFCs (3530 and 5661).
> Is there any specific reason decode is not implemented for archive?
>
>
>
> Also, I am not sure if there is any official windows client for NFSv4, I
> was using the one published by cohortfs. Is there some other windows client
> with which NFS Ganesha works seamlessly?
>
>
>
> Thanks,
>
> Sriram
>
>
> --
> [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

[Nfs-ganesha-devel] Why FATTR4_ARCHIVE does not have decode method?

[sriram patil]

Hi,

I was trying to use NFS Ganesha NFSv4 export using a windows client. But
this windows client is sending FATTR4_ARCHIVE in createattrs as part of
OPEN and fails to create any file.

decode method for FATTR4_ARCHIVE is not implemented, it returns NOOP. I
figured that the read-only attributes do not need a decode method, but
FATTR4_ARCHIVE is a read-write attribute according to RFCs (3530 and 5661).
Is there any specific reason decode is not implemented for archive?

Also, I am not sure if there is any official windows client for NFSv4, I
was using the one published by cohortfs. Is there some other windows client
with which NFS Ganesha works seamlessly?

Thanks,
Sriram
--
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) : final pxy_support_ex

[GerritHub]

>From Patrice LUCAS :

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


Change subject: FSAL_PROXY (support_ex without state) : final pxy_support_ex
..

FSAL_PROXY (support_ex without state) : final pxy_support_ex

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



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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ibbb85174a718b799df6ccb2083076cb454854a3b
Gerrit-Change-Number: 350166
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: RGW: enlighten rgw_lookup from readdir callbacks

[GerritHub]

>From Matt Benjamin :

Matt Benjamin has uploaded a new change for review. ( 
https://review.gerrithub.io/350192


Change subject: RGW: enlighten rgw_lookup from readdir callbacks
..

RGW: enlighten rgw_lookup from readdir callbacks

Teach readdir() callbacks to pass a new flag to rgw_lookup(),
which hints that the name is instantiable.

Change-Id: Ib269fb4e677b8e13135917cba3a884dc2c2c719a
Signed-off-by: Matt Benjamin 
---
M src/CMakeLists.txt
M src/FSAL/FSAL_RGW/handle.c
M src/FSAL/FSAL_RGW/internal.h
3 files changed, 19 insertions(+), 7 deletions(-)



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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib269fb4e677b8e13135917cba3a884dc2c2c719a
Gerrit-Change-Number: 350192
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Matt Benjamin 
--
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] [RFC] change struct state_t to include fsal_fd

[Frank Filz]

> On Do, 2017-02-23 at 04:40 -0500, William Allen Simpson wrote:
> > On 2/23/17 3:43 AM, Swen Schillig wrote:
> > >
> > > while removing some legacy GPFS code I stumbled over this
> > >
> > >   my_fd = (struct gpfs_fd *)(state + 1);
> > >
> > > which is probably just copied from an early version to all our
> > > FSALs.
> > >
> > Looks like the state struct is followed by per-FSAL independent data.
> >
> > A better design than this (or a union) would be container_of, so that
> > each FSAL is independent, and needs no centralized union.
> 
> True.
> For me, the main thing was the idea of having it as a part of state_t.
> I knew some might object to the split alloc idea, that's why I started the
> discussion with the union.
> 
> Anyway, all ideas raised so far are better than what's there, so let's see
what
> else is there to come and maybe we can agree to one then.

Yea, if we change it lets go with container_of. The union above burdens
every FSAL with the largest private fd whether it uses one or not.

container_of doesn't require split allocation.

However, don't add state_t to the private fd since the global fd does not
need a state and that would needlessly enlarge every FSAL object handle.

Instead make a containing structure:

struct myfsal_state_and_fd {
struct state_t state;
struct my_file_descriptor my_fd;
};

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] [RFC] change struct state_t to include fsal_fd

[Swen Schillig]

On Do, 2017-02-23 at 04:40 -0500, William Allen Simpson wrote:
> On 2/23/17 3:43 AM, Swen Schillig wrote:
> > 
> > while removing some legacy GPFS code I stumbled over this
> > 
> > my_fd = (struct gpfs_fd *)(state + 1);
> > 
> > which is probably just copied from an early version to all our
> > FSALs.
> > 
> Looks like the state struct is followed by per-FSAL independent data.
> 
> A better design than this (or a union) would be container_of, so that
> each FSAL is independent, and needs no centralized union.

True.
For me, the main thing was the idea of having it as a part of state_t.
I knew some might object to the split alloc idea, that's why I started
the discussion with the union.

Anyway, all ideas raised so far are better than what's there, so let's
see what else is there to come and maybe we can agree to one then.

Swen.

> 


--
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] [RFC] change struct state_t to include fsal_fd

[William Allen Simpson]

On 2/23/17 3:43 AM, Swen Schillig wrote:
> while removing some legacy GPFS code I stumbled over this
>
>   my_fd = (struct gpfs_fd *)(state + 1);
>
> which is probably just copied from an early version to all our FSALs.
>
Looks like the state struct is followed by per-FSAL independent data.

A better design than this (or a union) would be container_of, so that
each FSAL is independent, and needs no centralized union.


--
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] Change in ffilz/nfs-ganesha[next]: pull up ntirpc #41 & #42

[William Allen Simpson]

On 2/21/17 12:30 PM, GerritHub wrote:
> william.allen.simp...@gmail.com uploaded this change for *review*.
>
> View Change 
>
> pull up ntirpc #41
>
> Remove unused SVC_VC_CREATE_BOTHWAYS
>
This is now: pull up ntirpc #41 & #42

Many thanks to Daniel G for his review!

No idea why CEA failed for #41, but not for #41 + #42.  Didn't touch
anything related in either case.

On the Ganesha side, still only removes one unused symbol (never used
internally to ntirpc).

This patch series removes a lot of alloc/free activity for every new
transport connection, and makes a fair number of changes to headers
externally visible by Ganesha (and much more internally).  Most of the
client and server create calls are now inlines with const parameters,
perhaps generating smarter code.

"Napalm svc_ioq output threads" patch some time ago sped up the TCP
server output -- but had a side effect on the client call side of
handling the xids out of order.  (Only noticed affecting the NLM_async
code, but could have affected v4.x back-channels too.)  That's because
the first call ran the output queue for other senders, then handled its
own result.  This now uses a worker task queue instead, restoring the
xid ordering.

There's not enough testing of UDP and version 3.  Basically, just
mount, umount, cp in new file, then rm the new file.  Surely somebody
who uses v3 regularly has a better battery of tests.


--
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] [RFC] change struct state_t to include fsal_fd

[Swen Schillig]

On Do, 2017-02-23 at 14:28 +0530, Malahal Naineni wrote:
> That won't work for out of tree fsals, right? Either decouple them
> with a pointer or have a suitable macro to convert. To avoid split
> allocs, a macro would be better.
> 
> Regards, Malahal.
> PS: #define GPFS_STATE2FD(state) ((struct gpfs_fd
> *)((state)+sizeof(struct state_t))) # similar for other fsal!
> 
Didn't realize that there is support for out of tree FSALs.

But, isn't that the same thing just wrapped a little nicer  ?
I simply don't like code fragments with side-effects and I would
consider the removal of the gpfs_fd-memory by doing a free(state)
a side-effect.

However, I agree that this would already be an improvement with very
little effort.

Swen
> On Thu, Feb 23, 2017 at 2:13 PM, Swen Schillig 
> wrote:
> > 
> > All
> > 
> > while removing some legacy GPFS code I stumbled over this
> > 
> > my_fd = (struct gpfs_fd *)(state + 1);
> > 
> > which is probably just copied from an early version to all our
> > FSALs.
> > 
> > Since we're still in dev for 2.5 I'd volunteer and "transfer" this
> > into maybe this
> > 
> > struct state_t {
> > ...
> > union {
> > struct gluster_fd gluster;
> > struct ceph_fd fd ceph;
> > struct gpfs_fd gpfs;
> > struct vfs_fd vfs;
> > } fd;
> > }
> > 
> > comments ?
> > 
> > Swen
> > 
> > 
> > -
> > -
> > 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