All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Stuart Anderson <anderson@ligo.caltech.edu>, nfs@lists.sourceforge.net
Subject: Re: NFSv4 uninitialized mtime
Date: Thu, 28 Jun 2007 09:29:36 -0400	[thread overview]
Message-ID: <20070628092936.abfdac3a.jlayton@redhat.com> (raw)
In-Reply-To: <1183036785.6163.14.camel@heimdal.trondhjem.org>

On Thu, 28 Jun 2007 09:19:45 -0400
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:

> On Thu, 2007-06-28 at 08:01 -0400, Jeff Layton wrote:
> > Yes, it looks like Solaris is sending back a zeroed out attrmask on
> > exclusive create. I'm testing against:
> > 
> >                             Solaris Nevada snv_54 X86
> >            Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
> >                         Use is subject to license terms.
> >                            Assembled 04 December 2006
> > 
> > SunOS solaris 5.11 snv_54 i86pc i386 i86pc
> > 
> > My guess is that they're using NFSv3 semantics in their NFSv4 client to
> > set the mtime and atime, and that's why it "works" there. This patchrev
> > is pretty old by now, so they may have already patched this issue. I'll
> > see if I can patch it and test again.
> > 
> > All this, of course, is contingent upon my having interpreted the spec
> > correctly. I think I have, but wouldn't mind if someone sanity checked
> > me on it.
> 
> The only nit I can see is that the server is in theory allowed to store
> the cookie in some writable attribute other than atime/mtime, but I
> can't think of that many that would make sense. Perhaps time_backup and
> time_create for those servers that support them? However since we don't
> care about their values and since they don't support a
> SET_TO_SERVER_TIME4 option, I'm not sure we want to bother...
> 
> Trond
> 
> 

Yes, I didnt see other attrs that made sense either, but if we find any
it shouldn't be too hard to add them in.

In any case, Solaris pretty clearly seems to be using the mtime to
store the verifier but isn't setting the attrmask. I'd like to test a
later solaris rev, but I'm having some issues getting this image
patched.

Stuart, I'd recommend opening a case with Sun and referring them to
this discussion and the RFC. I'm pretty certain this is a server bug.
If Sun mentions this is already fixed, or issues a patch for it, then
please let us know in case others run into this problem.

Thanks,
-- 
Jeff Layton <jlayton@redhat.com>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-06-28 13:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-27 23:31 NFSv4 uninitialized mtime Stuart Anderson
2007-06-27 23:43 ` Trond Myklebust
2007-06-28  0:49   ` Stuart Anderson
2007-06-28  0:59     ` Stuart Anderson
2007-06-28  1:15       ` Jeff Layton
2007-06-28  2:53         ` Stuart Anderson
2007-06-28  3:09           ` Spencer Shepler
2007-06-28  3:23             ` Stuart Anderson
2007-06-28  3:30               ` Spencer Shepler
2007-06-28  3:44                 ` Stuart Anderson
2007-06-28  3:59                   ` Spencer Shepler
2007-06-28 13:32                     ` J. Bruce Fields
2007-06-28 10:41           ` Jeff Layton
2007-06-28 12:01             ` Jeff Layton
2007-06-28 13:19               ` Trond Myklebust
2007-06-28 13:29                 ` Jeff Layton [this message]
     [not found] <nfs-valinux.20070628064127.a769bc53.jlayton@redhat.com>
     [not found] ` <46857F06.102@ligo.caltech.edu>
     [not found]   ` <20070629181234.b70f6f7f.jlayton@redhat.com>
2007-06-29 22:31     ` Erik A. Espinoza
2007-06-30  2:35       ` Jeff Layton
2007-06-30  3:09         ` Erik A. Espinoza
2007-06-30 11:19           ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070628092936.abfdac3a.jlayton@redhat.com \
    --to=jlayton@redhat.com \
    --cc=anderson@ligo.caltech.edu \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.