* pynfs updates
@ 2013-09-30 18:17 Frank Filz
2013-09-30 22:11 ` Bruce Fields
0 siblings, 1 reply; 11+ messages in thread
From: Frank Filz @ 2013-09-30 18:17 UTC (permalink / raw)
To: Kernel NFS List, Bruce Fields, 'Ganesha NFS List'
Bruce,
Please pull the following branch that contains the pynfs updates I made at
BAT:
https://github.com/ffilz/pynfs/commits/master
Thanks
Frank
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pynfs updates
2013-09-30 18:17 pynfs updates Frank Filz
@ 2013-09-30 22:11 ` Bruce Fields
2013-09-30 23:54 ` Frank Filz
0 siblings, 1 reply; 11+ messages in thread
From: Bruce Fields @ 2013-09-30 22:11 UTC (permalink / raw)
To: Frank Filz; +Cc: Kernel NFS List, 'Ganesha NFS List'
On Mon, Sep 30, 2013 at 02:17:43PM -0400, Frank Filz wrote:
> Bruce,
>
> Please pull the following branch that contains the pynfs updates I made at
> BAT:
>
> https://github.com/ffilz/pynfs/commits/master
Thanks! A few questions:
- "4.1 server tests: Fix some exception handling": could you
include in the changelog and explanation of what problem this
fixes? (And ditto, maybe, for the following commit?)
- "Fix SEQ9d to work in home directory instead of root": did you
intend to include the chunk in nfs4.1/nfs4lib.py? It looks
irrelevant.
- "Add two SECINFO_NO_NAME tests for SECINFO_STYLE4_PARENT":
- SECNN3: is / required to have no parent? (I'd assumed
here that it would also be OK to follow the convention
that / is its own parent, but I'll admit to not having
thought about this much.)
- SECNN4: is env.home necessarily unequal to "/"? Would
seem better to do the lookup in a subdirectory just to
be certain.
--b.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: pynfs updates
2013-09-30 22:11 ` Bruce Fields
@ 2013-09-30 23:54 ` Frank Filz
2013-10-01 14:26 ` 'Bruce Fields'
0 siblings, 1 reply; 11+ messages in thread
From: Frank Filz @ 2013-09-30 23:54 UTC (permalink / raw)
To: 'Bruce Fields'
Cc: 'Kernel NFS List', 'Ganesha NFS List'
> Thanks! A few questions:
>
> - "4.1 server tests: Fix some exception handling": could you
> include in the changelog and explanation of what problem this
> fixes? (And ditto, maybe, for the following commit?)
Ok, I'll re-examine those. They were some things I stumbled on as I tried to
resolve some other issues with pynfs.
> - "Fix SEQ9d to work in home directory instead of root": did you
> intend to include the chunk in nfs4.1/nfs4lib.py? It looks
> irrelevant.
Hmm, will fix that.
> - "Add two SECINFO_NO_NAME tests for
> SECINFO_STYLE4_PARENT":
> - SECNN3: is / required to have no parent? (I'd assumed
> here that it would also be OK to follow the convention
> that / is its own parent, but I'll admit to not having
> thought about this much.)
>From LOOKUPP:
18.14.3. DESCRIPTION
The current filehandle is assumed to refer to a regular directory or
a named attribute directory. LOOKUPP assigns the filehandle for its
parent directory to be the current filehandle. If there is no parent
directory, an NFS4ERR_NOENT error must be returned. Therefore,
NFS4ERR_NOENT will be returned by the server when the current
filehandle is at the root or top of the server's file tree.
>From SECINFO_NO_NAME:
18.45.3. DESCRIPTION
...
If the style selected is SECINFO_STYLE4_PARENT,
then SECINFO should apply the same access methodology used for
LOOKUPP when evaluating the traversal to the parent directory.
...
If SECINFO_STYLE4_PARENT is specified and there is no parent
directory, SECINFO_NO_NAME MUST return NFS4ERR_NOENT.
> - SECNN4: is env.home necessarily unequal to "/"? Would
> seem better to do the lookup in a subdirectory just to
> be certain.
Env.home is the directory you specify on the command line, I think the
presumption is that it is a writeable file system. Pynfs creates tmp and
tree directories in home (and maybe some files also?). Guess if / was
writeable, you could specify /, so yea, maybe it should go into tmp.
A better test might actually be to do LOOKUP down to home and even into tmp,
looking for a junction, and then do the SECINFO_NO_NAME(parent) on the
directory handle just across the junction if one was found.
Thanks for the review.
Frank
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pynfs updates
2013-09-30 23:54 ` Frank Filz
@ 2013-10-01 14:26 ` 'Bruce Fields'
2013-10-01 14:30 ` 'Bruce Fields'
2013-10-01 18:21 ` Frank Filz
0 siblings, 2 replies; 11+ messages in thread
From: 'Bruce Fields' @ 2013-10-01 14:26 UTC (permalink / raw)
To: Frank Filz; +Cc: 'Kernel NFS List', 'Ganesha NFS List'
On Mon, Sep 30, 2013 at 07:54:52PM -0400, Frank Filz wrote:
> > - "Add two SECINFO_NO_NAME tests for
> > SECINFO_STYLE4_PARENT":
> > - SECNN3: is / required to have no parent? (I'd assumed
> > here that it would also be OK to follow the convention
> > that / is its own parent, but I'll admit to not having
> > thought about this much.)
>
> >From LOOKUPP:
>
> 18.14.3. DESCRIPTION
> The current filehandle is assumed to refer to a regular directory or
> a named attribute directory. LOOKUPP assigns the filehandle for its
> parent directory to be the current filehandle. If there is no parent
> directory, an NFS4ERR_NOENT error must be returned. Therefore,
> NFS4ERR_NOENT will be returned by the server when the current
> filehandle is at the root or top of the server's file tree.
OK, fine.
> > - SECNN4: is env.home necessarily unequal to "/"? Would
> > seem better to do the lookup in a subdirectory just to
> > be certain.
>
> Env.home is the directory you specify on the command line, I think the
> presumption is that it is a writeable file system. Pynfs creates tmp and
> tree directories in home (and maybe some files also?). Guess if / was
> writeable, you could specify /, so yea, maybe it should go into tmp.
Sounds good.
>
> A better test might actually be to do LOOKUP down to home and even into tmp,
> looking for a junction, and then do the SECINFO_NO_NAME(parent) on the
> directory handle just across the junction if one was found.
Yeah it'd be nice to check that cross-filesystem case but I don't think
it's necessary (and you still have to deal with the case where a
mountpoint's not found).
If tests at mountpoints were useful perhaps we could pass in a
mountpoint on the commandline. Or add some sort of export-configuration
interface to the serverhelper script and let pynfs setup exports itself.
--b.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pynfs updates
2013-10-01 14:26 ` 'Bruce Fields'
@ 2013-10-01 14:30 ` 'Bruce Fields'
2013-10-01 15:42 ` Frank Filz
2013-10-01 19:05 ` Frank Filz
2013-10-01 18:21 ` Frank Filz
1 sibling, 2 replies; 11+ messages in thread
From: 'Bruce Fields' @ 2013-10-01 14:30 UTC (permalink / raw)
To: Frank Filz; +Cc: 'Kernel NFS List', 'Ganesha NFS List'
One more problem: CSID10 is failing against the Linux server with
NFS4ERR_TOO_MANY_OPS, because each of those lookups is actually a full
lookup from PUTROOTFH to /, resulting in 17 ops on my setup. Could we
maybe work relative to the parent directory instead?
--b.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: pynfs updates
2013-10-01 14:30 ` 'Bruce Fields'
@ 2013-10-01 15:42 ` Frank Filz
2013-10-01 19:05 ` Frank Filz
1 sibling, 0 replies; 11+ messages in thread
From: Frank Filz @ 2013-10-01 15:42 UTC (permalink / raw)
To: 'Bruce Fields'
Cc: 'Kernel NFS List', 'Ganesha NFS List'
> One more problem: CSID10 is failing against the Linux server with
> NFS4ERR_TOO_MANY_OPS, because each of those lookups is actually a full
> lookup from PUTROOTFH to /, resulting in 17 ops on my setup. Could we
> maybe work relative to the parent directory instead?
Sure, I'll rework that one.
> > A better test might actually be to do LOOKUP down to home and even
> > into tmp, looking for a junction, and then do the
> > SECINFO_NO_NAME(parent) on the directory handle just across the
> junction if one was found.
>
> Yeah it'd be nice to check that cross-filesystem case but I don't think
it's
> necessary (and you still have to deal with the case where a mountpoint's
not
> found).
Well, the cross file system case is actually where you would need to use
SECINFO_NO_NAME. For some reason, you just have a handle to a directory
inside the export and want to navigate back up the tree. In doing so, you
cross back over a junction to a file system that is exported with a
different security flavor.
On the other hand, generally that higher level file system should include
all the security flavors used by the lower level file systems. Unless
SECINFO_NO_NAME lets you cross a junction where the new file system doesn't
have security flavors in common with the upper level file system, but I
don't think it does. Does anyone know the rationale of SECINFO_NO_NAME
(parent)? In fact is there really any use of SECINFO_NO_NAME other than to
get the secinfo for the root or public file handle? I guess it does also
allow a client to recover from the security flavors for a given file system
being changed on the fly (or perhaps after a migration event).
> If tests at mountpoints were useful perhaps we could pass in a mountpoint
> on the commandline. Or add some sort of export-configuration interface to
> the serverhelper script and let pynfs setup exports itself.
Frank
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: pynfs updates
2013-10-01 14:26 ` 'Bruce Fields'
2013-10-01 14:30 ` 'Bruce Fields'
@ 2013-10-01 18:21 ` Frank Filz
2013-10-01 18:45 ` 'Bruce Fields'
1 sibling, 1 reply; 11+ messages in thread
From: Frank Filz @ 2013-10-01 18:21 UTC (permalink / raw)
To: 'Bruce Fields'
Cc: 'Kernel NFS List', 'Ganesha NFS List'
> > > - SECNN4: is env.home necessarily unequal to "/"? Would
> > > seem better to do the lookup in a subdirectory just to
> > > be certain.
> >
> > Env.home is the directory you specify on the command line, I think the
> > presumption is that it is a writeable file system. Pynfs creates tmp
> > and tree directories in home (and maybe some files also?). Guess if /
> > was writeable, you could specify /, so yea, maybe it should go into tmp.
>
> Sounds good.
env.home does actually include traversing into tmp, so I will leave this
test alone.
> > A better test might actually be to do LOOKUP down to home and even
> > into tmp, looking for a junction, and then do the
> > SECINFO_NO_NAME(parent) on the directory handle just across the
> junction if one was found.
>
> Yeah it'd be nice to check that cross-filesystem case but I don't think
it's
> necessary (and you still have to deal with the case where a mountpoint's
not
> found).
>
> If tests at mountpoints were useful perhaps we could pass in a mountpoint
> on the commandline. Or add some sort of export-configuration interface to
> the serverhelper script and let pynfs setup exports itself.
Yea, that might be something interesting to explore at some point.
Frank
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pynfs updates
2013-10-01 18:21 ` Frank Filz
@ 2013-10-01 18:45 ` 'Bruce Fields'
0 siblings, 0 replies; 11+ messages in thread
From: 'Bruce Fields' @ 2013-10-01 18:45 UTC (permalink / raw)
To: Frank Filz; +Cc: 'Kernel NFS List', 'Ganesha NFS List'
On Tue, Oct 01, 2013 at 02:21:01PM -0400, Frank Filz wrote:
> > > > - SECNN4: is env.home necessarily unequal to "/"? Would
> > > > seem better to do the lookup in a subdirectory just to
> > > > be certain.
> > >
> > > Env.home is the directory you specify on the command line, I think the
> > > presumption is that it is a writeable file system. Pynfs creates tmp
> > > and tree directories in home (and maybe some files also?). Guess if /
> > > was writeable, you could specify /, so yea, maybe it should go into tmp.
> >
> > Sounds good.
>
> env.home does actually include traversing into tmp, so I will leave this
> test alone.
OK!
--b.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: pynfs updates
2013-10-01 14:30 ` 'Bruce Fields'
2013-10-01 15:42 ` Frank Filz
@ 2013-10-01 19:05 ` Frank Filz
2013-10-02 11:36 ` 'Bruce Fields'
1 sibling, 1 reply; 11+ messages in thread
From: Frank Filz @ 2013-10-01 19:05 UTC (permalink / raw)
To: 'Bruce Fields'
Cc: 'Kernel NFS List', 'Ganesha NFS List'
> One more problem: CSID10 is failing against the Linux server with
> NFS4ERR_TOO_MANY_OPS, because each of those lookups is actually a full
> lookup from PUTROOTFH to /, resulting in 17 ops on my setup. Could we
> maybe work relative to the parent directory instead?
Ok, was able to fix this by doing a LOOKUP sequence in a separate compound
followed by GETFH then in the compound that tests SAVEFH/RESTOREFH, just do
PUTFH that saved FH.
Things could be a lot smoother as discussed on IRC if the initialization
stored away env.home_fh.
Then with some work, this test could be simplified to:
SEQUENCE, PUTFH(env.home_fh), OPEN, GETFH, SAVEFH, PUTFH(env.home_fh),
RESTOREFH, CLOSE
Note that that GETFH is not actually used by this test, but presumably
open_create_op() would produce:
PUTFH(env.home_fh), OPEN, GETFH
Instead of what it currently does:
PUTROOTFH, LOOKUP..., OPEN, GETFH
The new branch is here:
https://github.com/ffilz/pynfs/commits/master
Frank
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pynfs updates
2013-10-01 19:05 ` Frank Filz
@ 2013-10-02 11:36 ` 'Bruce Fields'
2013-10-02 15:58 ` Frank Filz
0 siblings, 1 reply; 11+ messages in thread
From: 'Bruce Fields' @ 2013-10-02 11:36 UTC (permalink / raw)
To: Frank Filz; +Cc: 'Kernel NFS List', 'Ganesha NFS List'
On Tue, Oct 01, 2013 at 03:05:23PM -0400, Frank Filz wrote:
> > One more problem: CSID10 is failing against the Linux server with
> > NFS4ERR_TOO_MANY_OPS, because each of those lookups is actually a full
> > lookup from PUTROOTFH to /, resulting in 17 ops on my setup. Could we
> > maybe work relative to the parent directory instead?
>
> Ok, was able to fix this by doing a LOOKUP sequence in a separate compound
> followed by GETFH then in the compound that tests SAVEFH/RESTOREFH, just do
> PUTFH that saved FH.
>
> Things could be a lot smoother as discussed on IRC if the initialization
> stored away env.home_fh.
>
> Then with some work, this test could be simplified to:
>
> SEQUENCE, PUTFH(env.home_fh), OPEN, GETFH, SAVEFH, PUTFH(env.home_fh),
> RESTOREFH, CLOSE
>
> Note that that GETFH is not actually used by this test, but presumably
> open_create_op() would produce:
>
> PUTFH(env.home_fh), OPEN, GETFH
>
> Instead of what it currently does:
>
> PUTROOTFH, LOOKUP..., OPEN, GETFH
>
> The new branch is here:
>
> https://github.com/ffilz/pynfs/commits/master
Pulled, thanks!
--b.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: pynfs updates
2013-10-02 11:36 ` 'Bruce Fields'
@ 2013-10-02 15:58 ` Frank Filz
0 siblings, 0 replies; 11+ messages in thread
From: Frank Filz @ 2013-10-02 15:58 UTC (permalink / raw)
To: 'Bruce Fields'
Cc: 'Kernel NFS List', 'Ganesha NFS List'
> > The new branch is here:
> >
> > https://github.com/ffilz/pynfs/commits/master
>
> Pulled, thanks!
And thank you. Bakeathon was very productive for Ganesha in this department.
We went from 34 failures to 10 failures.
Thanks
Frank
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-10-02 15:59 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-30 18:17 pynfs updates Frank Filz
2013-09-30 22:11 ` Bruce Fields
2013-09-30 23:54 ` Frank Filz
2013-10-01 14:26 ` 'Bruce Fields'
2013-10-01 14:30 ` 'Bruce Fields'
2013-10-01 15:42 ` Frank Filz
2013-10-01 19:05 ` Frank Filz
2013-10-02 11:36 ` 'Bruce Fields'
2013-10-02 15:58 ` Frank Filz
2013-10-01 18:21 ` Frank Filz
2013-10-01 18:45 ` 'Bruce Fields'
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).