(no subject)

(no subject)

[Bernd Schubert]

Hi,

I'm just looking into a nfs i/o error problem. The server for /etc is unfs3 =

and the client is 2.6.16. I need some help regarding the nfs protocol.

Probably after updating mozilla /etc/mozilla/mozillarc was rewritten, I als=
o =

guess the inode was recycled.

A 'ls /etc/mozilla/mozillarc' worked fine and showed the correct results.
A 'cat /etc/mozilla/mozillarc' gave i/o errors.

Ethereal shows that the getattr gives the correct results, but the read cal=
l =

gives an NFS3ERR_STALE. =

Should the client in this case drop its filehandle cache and entirely =

re-request the file from the server, or is the given i/o error ok?

>From the point of the server, I guess, it already should return the =

NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the =

sources to see why it didn't. (unfs3 was compiled with inode generation =

number support).

After an 'echo 3 > /proc/sys/vm/drop_caches' the problem was solved for now=
, =

of course.


Thanks in advance,
	Bernd



-- =

Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Trond Myklebust]

On Wed, 2006-07-26 at 12:47 +0200, Bernd Schubert wrote:
> Hi,
> 
> I'm just looking into a nfs i/o error problem. The server for /etc is unfs3 
> and the client is 2.6.16. I need some help regarding the nfs protocol.
> 
> Probably after updating mozilla /etc/mozilla/mozillarc was rewritten, I also 
> guess the inode was recycled.
> 
> A 'ls /etc/mozilla/mozillarc' worked fine and showed the correct results.
> A 'cat /etc/mozilla/mozillarc' gave i/o errors.
> 
> Ethereal shows that the getattr gives the correct results, but the read call 
> gives an NFS3ERR_STALE. 
> Should the client in this case drop its filehandle cache and entirely 
> re-request the file from the server, or is the given i/o error ok?

The ESTALE error is usually correct. The client should not be reopening
the file unless it can guarantee that the file is the same as the one
that was originally open()ed.

> From the point of the server, I guess, it already should return the 
> NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the 
> sources to see why it didn't. (unfs3 was compiled with inode generation 
> number support).

Yes. Under the close-to-open caching model, the expectation is that the
filehandle will remain valid from the moment the successful GETATTR call
is sent in the first open() request until the last call to close(). If
unfs3 is caching filehandles, then it needs to use something like
inotify in order to figure out when to invalidate its cache.

Cheers,
  Trond


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: protocol question

[Bernd Schubert]

[Sorry that I forgot a proper subject first]

Hi Trond,

thanks for your help,

On Wednesday 26 July 2006 13:43, Trond Myklebust wrote:
> On Wed, 2006-07-26 at 12:47 +0200, Bernd Schubert wrote:
[...]
> > Ethereal shows that the getattr gives the correct results, but the read
> > call gives an NFS3ERR_STALE.
> > Should the client in this case drop its filehandle cache and entirely
> > re-request the file from the server, or is the given i/o error ok?
>
> The ESTALE error is usually correct. The client should not be reopening
> the file unless it can guarantee that the file is the same as the one
> that was originally open()ed.

But the client returns an i/o error to the userspace, is this correct?

>
> > From the point of the server, I guess, it already should return the
> > NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the
> > sources to see why it didn't. (unfs3 was compiled with inode generation
> > number support).
>
> Yes. Under the close-to-open caching model, the expectation is that the
> filehandle will remain valid from the moment the successful GETATTR call
> is sent in the first open() request until the last call to close(). If
> unfs3 is caching filehandles, then it needs to use something like
> inotify in order to figure out when to invalidate its cache.

Hmm, but the inode generation number should have changed, isn't it there fo=
r =

exactly this purpose? I also restarted unfs3 first, so it didn't have any =

filehandles cached.


Thanks again,
	Bernd

-- =

Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: protocol question

[Trond Myklebust]

On Wed, 2006-07-26 at 13:56 +0200, Bernd Schubert wrote:
> [Sorry that I forgot a proper subject first]
> 
> Hi Trond,
> 
> thanks for your help,
> 
> On Wednesday 26 July 2006 13:43, Trond Myklebust wrote:
> > On Wed, 2006-07-26 at 12:47 +0200, Bernd Schubert wrote:
> [...]
> > > Ethereal shows that the getattr gives the correct results, but the read
> > > call gives an NFS3ERR_STALE.
> > > Should the client in this case drop its filehandle cache and entirely
> > > re-request the file from the server, or is the given i/o error ok?
> >
> > The ESTALE error is usually correct. The client should not be reopening
> > the file unless it can guarantee that the file is the same as the one
> > that was originally open()ed.
> 
> But the client returns an i/o error to the userspace, is this correct?

No. It will return an ESTALE to userspace in this case.

> > > From the point of the server, I guess, it already should return the
> > > NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the
> > > sources to see why it didn't. (unfs3 was compiled with inode generation
> > > number support).
> >
> > Yes. Under the close-to-open caching model, the expectation is that the
> > filehandle will remain valid from the moment the successful GETATTR call
> > is sent in the first open() request until the last call to close(). If
> > unfs3 is caching filehandles, then it needs to use something like
> > inotify in order to figure out when to invalidate its cache.
> 
> Hmm, but the inode generation number should have changed, isn't it there for 
> exactly this purpose? I also restarted unfs3 first, so it didn't have any 
> filehandles cached.

Right. The inode generation number changes when the inode number is
reused. After that, any NFS rpc request containing the filehandle with
the old generation number should receive an immediate NFSERR3_STALE.

My point about inotify was merely a way to help enforce that in the case
where a userland-based server might want to cache filehandles. I've no
idea whether or not unfs3 actually does that sort of thing.

Cheers,
  Trond


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: protocol question

[Trond Myklebust]

On Wed, 2006-07-26 at 08:20 -0400, Trond Myklebust wrote:
> Right. The inode generation number changes when the inode number is
> reused. After that, any NFS rpc request containing the filehandle with
> the old generation number should receive an immediate NFSERR3_STALE.

Oops. Actually, it would be more correct to say that the filehandle is
invalidated immediately once the file has been deleted on the server.

The generation number is there in order to ensure that the old
filehandle is not 'resurrected' when the inode number is reused.

Cheers,
  Trond


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: protocol question

[Bernd Schubert]

> > But the client returns an i/o error to the userspace, is this correct?
>
> No. It will return an ESTALE to userspace in this case.

Sorry, I didn't express myself properly, it _did_ return i/o error.

[...]
> Right. The inode generation number changes when the inode number is
> reused. After that, any NFS rpc request containing the filehandle with
> the old generation number should receive an immediate NFSERR3_STALE.

> Oops. Actually, it would be more correct to say that the filehandle is
> invalidated immediately once the file has been deleted on the server.
>
> The generation number is there in order to ensure that the old
> filehandle is not 'resurrected' when the inode number is reused.

I need to have a look how Pascal actually used the generation numbers.

>
> My point about inotify was merely a way to help enforce that in the case
> where a userland-based server might want to cache filehandles. I've no
> idea whether or not unfs3 actually does that sort of thing.

There is a cache, but thats the part I so far never looked into.

Thanks a lot for your help,
	Bernd

-- =

Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs