headers
rick | 3 May 2004 18:10
Picon

NFSv4 testing tool

Just in case you're interested, I've constructed a crude "internet emulator"
using OpenBSD3.4 on a box with 2 net interfaces. It's configured as a
router, with controllable delay and packet loss. I'm finding it useful
for NFSv4 testing. If you are interested, you can grab it:
anonymous ftp: snowhite.cis.uoguelph.ca (131.104.48.1)
in pub/nfsv4/delayrouter-openbsd3.tar.gz.

I'll also bring to Ann Arbor, rick

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Talpey, Thomas | 3 May 2004 19:38
Picon

Re: NFSv4 testing tool

Cool! A lot like the old TCP/IP bakeoff "Flakeway" in RFC1025,
except that one (intentionally) reordered packets too.

I'm not sure about packet loss control for v4 - because of
the presence of TCP, I'd guess that it's effectively inserting
a long delay at random intervals (while the retransmit occurs)?
The question I would have, assuming this is correct, is whether
TCP fast-retransmit would kick in and eliminate the timeout.

Sounds like a good thing to have. What TCPs is it killing? :-)

Tom.


At 12:10 PM 5/3/2004, rick <at> snowhite.cis.uoguelph.ca wrote:
>Just in case you're interested, I've constructed a crude "internet emulator"
>using OpenBSD3.4 on a box with 2 net interfaces. It's configured as a
>router, with controllable delay and packet loss. I'm finding it useful
>for NFSv4 testing. If you are interested, you can grab it:
>anonymous ftp: snowhite.cis.uoguelph.ca (131.104.48.1)
>in pub/nfsv4/delayrouter-openbsd3.tar.gz.
>
>I'll also bring to Ann Arbor, rick
>
>_______________________________________________
>nfsv4 mailing list
>nfsv4 <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/nfsv4

Permalink | Reply | 0 comments |
headers
William A.(Andy) Adamson | 3 May 2004 19:58
Picon
Favicon

Announcement of the 2004 Interim NFSv4 IETF meeting

CITI is pleased to host the next Interim NFSv4 IETF meeting Wednesday June 9, 
9:00AM - 5:00 PM at the Michigan League, 911 N. University, Ann Arbor Michigan.

http://www.umich.edu/~league

The meeting is held during the 10th NFSv4 Bakeathon also held at CITI June 
7-11. See http://www.citi.umich.edu/projects/nfsv4/citi_bakeathon/10th_nfsv4_ba
keathon.html for hotel and travel information. Bakeathon registration is not 
necessary for meeting participation.

Meeting details will be posted soon.

-->Andy Adamson

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Stevan Steve Allen | 15 May 2004 17:26
Picon
Favicon

FYI: Readdir not allowed on NFS pseudo root


FYI:

Our NFS server sits on top of two operating systems, one UNIX and one non hierarchical.  An OS restriction in this environment is READDIR is not allowed from the new NFS pseudo root.  Lookup will be allowed.  

A GETATTR for our NFS pseudo root will return a mode with execute permission bits on to permit change dir, all read and write mode bits are off.

Thanks,
Stevan C. Allen
Permalink | Reply | 2 comments |
headers
Spencer Shepler | 15 May 2004 23:25
Picon

Re: FYI: Readdir not allowed on NFS pseudo root


On May 15, 2004, at 10:26 AM, Stevan Steve Allen wrote:

>
> FYI:
>
> Our NFS server sits on top of two operating systems, one UNIX and one 
> non hierarchical.  An OS restriction in this environment is READDIR is 
> not allowed from the new NFS pseudo root.  Lookup will be allowed.  
>
> A GETATTR for our NFS pseudo root will return a mode with execute 
> permission bits on to permit change dir, all read and write mode bits 
> are off.

Would you be able to be more specific about the operating
environments for which this server will be available?  This will
allow the client implementors to be able to respond to user
questions about things not working when the client mounts / from
the server.

Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 1 comment |
headers
Stevan Steve Allen | 16 May 2004 06:18
Picon
Favicon

Re: FYI: Readdir not allowed on NFS pseudo root


Spencer, my intro to Open Systems is still somewhat limited.  Without mount support in v4, are you inquiring about Mount in general?

The operating system is IBM z/OS which contains a flat filesystem with a UNIX layer.  The z/OS NFSv3 server will access files directly (filesysA) or through the UNIX layer (filesysB).

Basically, z/OS NFSv3 represents two unconnected filesystems where NFSv4 has introduced a connecting root.

The flat file system is represented by qualified filenames such as USER.PROJECTS.NFS.ATTR.  A problem for z/OS NFSv3 is a READDIR of the flat filesystem root represents every file in the system.  This is not permitted by the z/OS catalog facility due to the output size.  

To address the z/OS 'list all' restriction, z/OS mount support REQUIRES a mount on a filename prefix or UNIX directory.  NFSv3 converts flat filenames to a hierarchical directory structure.  A mount location may be USER or NFS.EXPORTED or /HFS/u/pub allowing a READDIR from this point on.

The current plan is to return NFS4ERR_NOENT for a READDIR of the NFSv4 pseudo root.  e.g. the pseudo root will take on the current restrictions of the flat filesys root.  

z/OS NFSv3 Pubs:
http://www.ibm.com/servers/eserver/zseries/zos/zos_elefeat.html#n


On May 15, 2004, at 10:26 AM, Stevan Steve Allen wrote:

>
> FYI:
>
> Our NFS server sits on top of two operating systems, one UNIX and one
> non hierarchical.  An OS restriction in this environment is READDIR is
> not allowed from the new NFS pseudo root.  Lookup will be allowed.  
>
> A GETATTR for our NFS pseudo root will return a mode with execute
> permission bits on to permit change dir, all read and write mode bits
> are off.

Would you be able to be more specific about the operating
environments for which this server will be available?  This will
allow the client implementors to be able to respond to user
questions about things not working when the client mounts / from
the server.

Spencer


Permalink | Reply | 0 comments |
headers
rick | 16 May 2004 20:53
Picon

creating a named attribute

In Sec. 5.3, it seems to indicate that a Create Op can be used to create
a named attribute.

However, in the xdr in Sec. 18, NF4NAMEDATTR is not listed in the
union createtype4 switch for Create. Is this just a typo?

Thanks, rick

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 7 comments |
headers
Jim Rees | 16 May 2004 22:29
Picon

Re: FYI: Readdir not allowed on NFS pseudo root

  The current plan is to return NFS4ERR_NOENT for a READDIR of the NFSv4 
  pseudo root.

That seems wrong to me.  It would imply that the root does not exist, and in
my opinion would violate the spec.  I think you want something more like
NFS4ERR_ACCESS.

Other than that, an unreadable root seems acceptable, although unfriendly.
Why not put your flat file system somewhere below the root, and make that
unreadable?

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Noveck, Dave | 16 May 2004 23:02
Picon

RE: FYI: Readdir not allowed on NFS pseudo root

NFS4ERR_NOENT is not listed as a valid error for READDIR.

-----Original Message-----
From: Jim Rees [mailto:rees <at> umich.edu]
Sent: Sunday, May 16, 2004 4:29 PM
To: nfsv4 <at> ietf.org
Subject: Re: [nfsv4] FYI: Readdir not allowed on NFS pseudo root 

  The current plan is to return NFS4ERR_NOENT for a READDIR of the NFSv4 
  pseudo root.

That seems wrong to me.  It would imply that the root does not exist, and in
my opinion would violate the spec.  I think you want something more like
NFS4ERR_ACCESS.

Other than that, an unreadable root seems acceptable, although unfriendly.
Why not put your flat file system somewhere below the root, and make that
unreadable?

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 1 comment |
headers
Spencer Shepler | 17 May 2004 03:41
Picon

Re: creating a named attribute


On May 16, 2004, at 1:53 PM, rick <at> snowhite.cis.uoguelph.ca wrote:

> In Sec. 5.3, it seems to indicate that a Create Op can be used to 
> create
> a named attribute.
>
> However, in the xdr in Sec. 18, NF4NAMEDATTR is not listed in the
> union createtype4 switch for Create. Is this just a typo?

Section 5.3 is wrong.  Named attributes are created just like regular
files are created, with the OPEN operation.  CREATE is just for
objects of the types enumerated in createtype4.

Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 6 comments |

Gmane