nfs + Reiser4

nfs + Reiser4

[gg-B3jsHfKwJfLR7s880joybQ]

Hi,

I am having serious headaches using nfs between a reiser4 server and arm  
client.
Both on 2.6.29 vintage kernels.

Files are constantly getting out of sync.

Example :

boot ARM via nfs
edit lighttpd.conf on ARM
check edit is visible on server. OK

reboot ARM
check file : reverted to an earlier state.
check server: edited version still showing.


This is just one example of serious userablity issues. I have also seen a  
revert 10s later reopening the same file on the ARM.

Is this possibly related to R4 + nfs ?

TIA.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[J. Bruce Fields]

On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
> I am having serious headaches using nfs between a reiser4 server and arm  
> client.
> Both on 2.6.29 vintage kernels.
> 
> Files are constantly getting out of sync.
> 
> Example :
> 
> boot ARM via nfs
> edit lighttpd.conf on ARM
> check edit is visible on server. OK
> 
> reboot ARM
> check file : reverted to an earlier state.
> check server: edited version still showing.

So, on a freshly booted NFS client, you're opening and reading a file
and seeing file data that isn't even on the NFS server any more?

That's beyond bizarre.  Do you have a reliable way to reproduce the
problem?

--b.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[Chuck Lever]

On 04/07/2010 01:34 PM, J. Bruce Fields wrote:
> On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>> I am having serious headaches using nfs between a reiser4 server and arm
>> client.
>> Both on 2.6.29 vintage kernels.
>>
>> Files are constantly getting out of sync.
>>
>> Example :
>>
>> boot ARM via nfs
>> edit lighttpd.conf on ARM
>> check edit is visible on server. OK
>>
>> reboot ARM
>> check file : reverted to an earlier state.
>> check server: edited version still showing.
>
> So, on a freshly booted NFS client, you're opening and reading a file
> and seeing file data that isn't even on the NFS server any more?
>
> That's beyond bizarre.  Do you have a reliable way to reproduce the
> problem?

Could be XID replay.

-- 
chuck[dot]lever[at]oracle[dot]com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[J. Bruce Fields]

On Wed, Apr 07, 2010 at 02:44:01PM -0400, Chuck Lever wrote:
> On 04/07/2010 01:34 PM, J. Bruce Fields wrote:
>> On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>>> I am having serious headaches using nfs between a reiser4 server and arm
>>> client.
>>> Both on 2.6.29 vintage kernels.
>>>
>>> Files are constantly getting out of sync.
>>>
>>> Example :
>>>
>>> boot ARM via nfs
>>> edit lighttpd.conf on ARM
>>> check edit is visible on server. OK
>>>
>>> reboot ARM
>>> check file : reverted to an earlier state.
>>> check server: edited version still showing.
>>
>> So, on a freshly booted NFS client, you're opening and reading a file
>> and seeing file data that isn't even on the NFS server any more?
>>
>> That's beyond bizarre.  Do you have a reliable way to reproduce the
>> problem?
>
> Could be XID replay.

I'm not following you.  You're thinking of a read request after the
reboot that unluckily reuses an old XID and gets stale data from the
servers reply cache?  Or something else?

--b.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[Chuck Lever]

On 04/07/2010 02:51 PM, J. Bruce Fields wrote:
> On Wed, Apr 07, 2010 at 02:44:01PM -0400, Chuck Lever wrote:
>> On 04/07/2010 01:34 PM, J. Bruce Fields wrote:
>>> On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>>>> I am having serious headaches using nfs between a reiser4 server and arm
>>>> client.
>>>> Both on 2.6.29 vintage kernels.
>>>>
>>>> Files are constantly getting out of sync.
>>>>
>>>> Example :
>>>>
>>>> boot ARM via nfs
>>>> edit lighttpd.conf on ARM
>>>> check edit is visible on server. OK
>>>>
>>>> reboot ARM
>>>> check file : reverted to an earlier state.
>>>> check server: edited version still showing.
>>>
>>> So, on a freshly booted NFS client, you're opening and reading a file
>>> and seeing file data that isn't even on the NFS server any more?
>>>
>>> That's beyond bizarre.  Do you have a reliable way to reproduce the
>>> problem?
>>
>> Could be XID replay.
>
> I'm not following you.  You're thinking of a read request after the
> reboot that unluckily reuses an old XID and gets stale data from the
> servers reply cache?  Or something else?

Nothing unlucky about it.  Just after a boot, if the client 
implementation isn't careful about choosing an initial XID, (eg it 
always starts with a psuedorandom number but uses the same seed every 
time), it will hit the server's replay cache.

This can be quite reproducible for NFSROOT and a quiescent server.

-- 
chuck[dot]lever[at]oracle[dot]com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[J. Bruce Fields]

On Wed, Apr 07, 2010 at 02:59:36PM -0400, Chuck Lever wrote:
> On 04/07/2010 02:51 PM, J. Bruce Fields wrote:
>> On Wed, Apr 07, 2010 at 02:44:01PM -0400, Chuck Lever wrote:
>>> On 04/07/2010 01:34 PM, J. Bruce Fields wrote:
>>>> On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>>>>> I am having serious headaches using nfs between a reiser4 server and arm
>>>>> client.
>>>>> Both on 2.6.29 vintage kernels.
>>>>>
>>>>> Files are constantly getting out of sync.
>>>>>
>>>>> Example :
>>>>>
>>>>> boot ARM via nfs
>>>>> edit lighttpd.conf on ARM
>>>>> check edit is visible on server. OK
>>>>>
>>>>> reboot ARM
>>>>> check file : reverted to an earlier state.
>>>>> check server: edited version still showing.
>>>>
>>>> So, on a freshly booted NFS client, you're opening and reading a file
>>>> and seeing file data that isn't even on the NFS server any more?
>>>>
>>>> That's beyond bizarre.  Do you have a reliable way to reproduce the
>>>> problem?
>>>
>>> Could be XID replay.
>>
>> I'm not following you.  You're thinking of a read request after the
>> reboot that unluckily reuses an old XID and gets stale data from the
>> servers reply cache?  Or something else?
>
> Nothing unlucky about it.  Just after a boot, if the client  
> implementation isn't careful about choosing an initial XID, (eg it  
> always starts with a psuedorandom number but uses the same seed every  
> time), it will hit the server's replay cache.

Hm, OK.

> This can be quite reproducible for NFSROOT and a quiescent server.

The Linux server doesn't cache READ results as far as I can tell.

--b.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[Chuck Lever]

On 04/07/2010 03:20 PM, J. Bruce Fields wrote:
> On Wed, Apr 07, 2010 at 02:59:36PM -0400, Chuck Lever wrote:
>> On 04/07/2010 02:51 PM, J. Bruce Fields wrote:
>>> On Wed, Apr 07, 2010 at 02:44:01PM -0400, Chuck Lever wrote:
>>>> On 04/07/2010 01:34 PM, J. Bruce Fields wrote:
>>>>> On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>>>>>> I am having serious headaches using nfs between a reiser4 server and arm
>>>>>> client.
>>>>>> Both on 2.6.29 vintage kernels.
>>>>>>
>>>>>> Files are constantly getting out of sync.
>>>>>>
>>>>>> Example :
>>>>>>
>>>>>> boot ARM via nfs
>>>>>> edit lighttpd.conf on ARM
>>>>>> check edit is visible on server. OK
>>>>>>
>>>>>> reboot ARM
>>>>>> check file : reverted to an earlier state.
>>>>>> check server: edited version still showing.
>>>>>
>>>>> So, on a freshly booted NFS client, you're opening and reading a file
>>>>> and seeing file data that isn't even on the NFS server any more?
>>>>>
>>>>> That's beyond bizarre.  Do you have a reliable way to reproduce the
>>>>> problem?
>>>>
>>>> Could be XID replay.
>>>
>>> I'm not following you.  You're thinking of a read request after the
>>> reboot that unluckily reuses an old XID and gets stale data from the
>>> servers reply cache?  Or something else?
>>
>> Nothing unlucky about it.  Just after a boot, if the client
>> implementation isn't careful about choosing an initial XID, (eg it
>> always starts with a psuedorandom number but uses the same seed every
>> time), it will hit the server's replay cache.
>
> Hm, OK.
>
>> This can be quite reproducible for NFSROOT and a quiescent server.
>
> The Linux server doesn't cache READ results as far as I can tell.

OK.  Some servers do.

Sounds like a server side network trace is in order.

-- 
chuck[dot]lever[at]oracle[dot]com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[Trond Myklebust]

On Wed, 2010-04-07 at 15:20 -0400, J. Bruce Fields wrote: 
> On Wed, Apr 07, 2010 at 02:59:36PM -0400, Chuck Lever wrote:
> > On 04/07/2010 02:51 PM, J. Bruce Fields wrote:
> >> On Wed, Apr 07, 2010 at 02:44:01PM -0400, Chuck Lever wrote:
> >>> On 04/07/2010 01:34 PM, J. Bruce Fields wrote:
> >>>> On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
> >>>>> I am having serious headaches using nfs between a reiser4 server and arm
> >>>>> client.
> >>>>> Both on 2.6.29 vintage kernels.
> >>>>>
> >>>>> Files are constantly getting out of sync.
> >>>>>
> >>>>> Example :
> >>>>>
> >>>>> boot ARM via nfs
> >>>>> edit lighttpd.conf on ARM
> >>>>> check edit is visible on server. OK
> >>>>>
> >>>>> reboot ARM
> >>>>> check file : reverted to an earlier state.
> >>>>> check server: edited version still showing.
> >>>>
> >>>> So, on a freshly booted NFS client, you're opening and reading a file
> >>>> and seeing file data that isn't even on the NFS server any more?
> >>>>
> >>>> That's beyond bizarre.  Do you have a reliable way to reproduce the
> >>>> problem?
> >>>
> >>> Could be XID replay.
> >>
> >> I'm not following you.  You're thinking of a read request after the
> >> reboot that unluckily reuses an old XID and gets stale data from the
> >> servers reply cache?  Or something else?
> >
> > Nothing unlucky about it.  Just after a boot, if the client  
> > implementation isn't careful about choosing an initial XID, (eg it  
> > always starts with a psuedorandom number but uses the same seed every  
> > time), it will hit the server's replay cache.
> 
> Hm, OK.
> 
> > This can be quite reproducible for NFSROOT and a quiescent server.
> 
> The Linux server doesn't cache READ results as far as I can tell.
> 
> --b.

Is he perhaps using the Debian unfsd or some other user space nfs
server?

Cheers
  Trond

Re: nfs + Reiser4

[gg-B3jsHfKwJfLR7s880joybQ]

On 04/07/10 23:09, Trond Myklebust wrote:
> On Wed, 2010-04-07 at 15:20 -0400, J. Bruce Fields wrote:
>> On Wed, Apr 07, 2010 at 02:59:36PM -0400, Chuck Lever wrote:
>>> On 04/07/2010 02:51 PM, J. Bruce Fields wrote:
>>>> On Wed, Apr 07, 2010 at 02:44:01PM -0400, Chuck Lever wrote:
>>>>> On 04/07/2010 01:34 PM, J. Bruce Fields wrote:
>>>>>> On Tue, Apr 06, 2010 at 07:52:21PM +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>>>>>>> I am having serious headaches using nfs between a reiser4 server and arm
>>>>>>> client.
>>>>>>> Both on 2.6.29 vintage kernels.
>>>>>>>
>>>>>>> Files are constantly getting out of sync.
>>>>>>>
>>>>>>> Example :
>>>>>>>
>>>>>>> boot ARM via nfs
>>>>>>> edit lighttpd.conf on ARM
>>>>>>> check edit is visible on server. OK
>>>>>>>
>>>>>>> reboot ARM
>>>>>>> check file : reverted to an earlier state.
>>>>>>> check server: edited version still showing.
>>>>>>
>>>>>> So, on a freshly booted NFS client, you're opening and reading a file
>>>>>> and seeing file data that isn't even on the NFS server any more?
>>>>>>
>>>>>> That's beyond bizarre.  Do you have a reliable way to reproduce the
>>>>>> problem?
>>>>>
>>>>> Could be XID replay.
>>>>
>>>> I'm not following you.  You're thinking of a read request after the
>>>> reboot that unluckily reuses an old XID and gets stale data from the
>>>> servers reply cache?  Or something else?
>>>
>>> Nothing unlucky about it.  Just after a boot, if the client
>>> implementation isn't careful about choosing an initial XID, (eg it
>>> always starts with a psuedorandom number but uses the same seed every
>>> time), it will hit the server's replay cache.
>>
>> Hm, OK.
>>
>>> This can be quite reproducible for NFSROOT and a quiescent server.
>>
>> The Linux server doesn't cache READ results as far as I can tell.
>>
>> --b.
>
> Is he perhaps using the Debian unfsd or some other user space nfs
> server?
>
> Cheers
>    Trond
>
>

Hi,

thanks for all the activity.

Some more info on the machines in question.

server: gentoo linux 2.6.29 kernel patched for R4 
.net-fs/nfs-utils-1.2.1  Recently added nfs4 to existing nfs3 in kernel. 
This did not seem to improve/deteriorate the problem. This has been an 
issue ever since I used nfs to remote boot the client.

Client. ARM SBC also running 2.6.29 nfs3. Similar issues seen when 
running manufacturer's 2.4 kernel. Suggests problem is on server.

Redboot bootstrap loads kernel via http then boots with nfsroot supplied 
by server.

All specific issues related here are as seen yesterday with both running 
2.6.29.

The set up is damn near unusable as it is behaving now . Files are 
constantly out of sync. Changes seem to stay or disappear in a more or 
less arbitrary fashion (ie no percievable repeatable pattern or cause). 
Files often get some kind of merge state which is neither the state on 
the server , nor the last saved state on the client.

/dev/root on / type nfs
(rw,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nointr,nolock,\proto=udp,timeo=\
11,retrans=3,sec=sys,addr=192.168.1.3)

I note vers=2 here, does this maybe indicate some trouble with the 
initial negotiation and fallback to nfs2 ?

I don't have one clear , reproducible problem because the results are so 
erratic. But just editting a file with vi on the client and reopening it 
will give incorrect results 8 time out of 10.

The reboot issue killed me. I thought is desperation that that would at 
least mean I got a clean copy.

Thanks for your interest.

Re: nfs + Reiser4

[Bernd Schubert]

On Tuesday 06 April 2010, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
> Hi,
> 
> I am having serious headaches using nfs between a reiser4 server and arm
> client.
> Both on 2.6.29 vintage kernels.
> 
> Files are constantly getting out of sync.
> 
> Example :
> 
> boot ARM via nfs
> edit lighttpd.conf on ARM
> check edit is visible on server. OK
> 
> reboot ARM
> check file : reverted to an earlier state.
> check server: edited version still showing.
> 
> 
> This is just one example of serious userablity issues. I have also seen a
> revert 10s later reopening the same file on the ARM.
> 
> Is this possibly related to R4 + nfs ?

Reminds me about an old bug report I wrote and which nobody ever cared about:

http://article.gmane.org/gmane.linux.nfs/9867/match=


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

Re: nfs + Reiser4

[Trond Myklebust]

On Wed, 2010-04-07 at 23:33 +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote: 
> Some more info on the machines in question.
> 
> server: gentoo linux 2.6.29 kernel patched for R4 
> .net-fs/nfs-utils-1.2.1  Recently added nfs4 to existing nfs3 in kernel. 
> This did not seem to improve/deteriorate the problem. This has been an 
> issue ever since I used nfs to remote boot the client.
> 
> Client. ARM SBC also running 2.6.29 nfs3. Similar issues seen when 
> running manufacturer's 2.4 kernel. Suggests problem is on server.
> 
> Redboot bootstrap loads kernel via http then boots with nfsroot supplied 
> by server.
> 
> All specific issues related here are as seen yesterday with both running 
> 2.6.29.
> 
> The set up is damn near unusable as it is behaving now . Files are 
> constantly out of sync. Changes seem to stay or disappear in a more or 
> less arbitrary fashion (ie no percievable repeatable pattern or cause). 
> Files often get some kind of merge state which is neither the state on 
> the server , nor the last saved state on the client.
> 
> /dev/root on / type nfs
> (rw,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nointr,nolock,\proto=udp,timeo=\
> 11,retrans=3,sec=sys,addr=192.168.1.3)
> 
> I note vers=2 here, does this maybe indicate some trouble with the 
> initial negotiation and fallback to nfs2 ?
> 
> I don't have one clear , reproducible problem because the results are so 
> erratic. But just editting a file with vi on the client and reopening it 
> will give incorrect results 8 time out of 10.
> 
> The reboot issue killed me. I thought is desperation that that would at 
> least mean I got a clean copy.

OK, so clearly not a userspace NFS issue then.

Just out of interest, are you able to reproduce this problem with other
underlying filesystems? Reiser4 has never been merged into the mainline
kernel, so I doubt that any one of us has a test setup.

Cheers
  Trond

Re: nfs + Reiser4

[gg-B3jsHfKwJfLR7s880joybQ]

On 04/08/10 00:49, Trond Myklebust wrote:
> On Wed, 2010-04-07 at 23:33 +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>> Some more info on the machines in question.
>>
>> server: gentoo linux 2.6.29 kernel patched for R4
>> .net-fs/nfs-utils-1.2.1  Recently added nfs4 to existing nfs3 in kernel.
>> This did not seem to improve/deteriorate the problem. This has been an
>> issue ever since I used nfs to remote boot the client.
>>
>> Client. ARM SBC also running 2.6.29 nfs3. Similar issues seen when
>> running manufacturer's 2.4 kernel. Suggests problem is on server.
>>
>> Redboot bootstrap loads kernel via http then boots with nfsroot supplied
>> by server.
>>
>> All specific issues related here are as seen yesterday with both running
>> 2.6.29.
>>
>> The set up is damn near unusable as it is behaving now . Files are
>> constantly out of sync. Changes seem to stay or disappear in a more or
>> less arbitrary fashion (ie no percievable repeatable pattern or cause).
>> Files often get some kind of merge state which is neither the state on
>> the server , nor the last saved state on the client.
>>
>> /dev/root on / type nfs
>> (rw,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nointr,nolock,\proto=udp,timeo=\
>> 11,retrans=3,sec=sys,addr=192.168.1.3)
>>
>> I note vers=2 here, does this maybe indicate some trouble with the
>> initial negotiation and fallback to nfs2 ?
>>
>> I don't have one clear , reproducible problem because the results are so
>> erratic. But just editting a file with vi on the client and reopening it
>> will give incorrect results 8 time out of 10.
>>
>> The reboot issue killed me. I thought is desperation that that would at
>> least mean I got a clean copy.
>
> OK, so clearly not a userspace NFS issue then.
>
> Just out of interest, are you able to reproduce this problem with other
> underlying filesystems? Reiser4 has never been merged into the mainline
> kernel, so I doubt that any one of us has a test setup.
>
> Cheers
>    Trond
>
>

OK , I just tried this on ext3 partition and I'm not seeing the erratic 
behaviour.  So this may be down to a bad reaction between nfs and R4 as 
I suspected.

However, I am still seeing vers=2 , does this indicate some problem in 
initial negociation and a drop back to nfs2 ?

/dev/root on / type nfs 
(rw,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nointr,nolock,proto=udp,timeo=11,retrans=3,sec=sys,addr=192.168.1.3) 


regards,

Re: nfs + Reiser4

[Trond Myklebust]

On Thu, 2010-04-08 at 23:03 +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote: 
> OK , I just tried this on ext3 partition and I'm not seeing the erratic 
> behaviour.  So this may be down to a bad reaction between nfs and R4 as 
> I suspected.
> 
> However, I am still seeing vers=2 , does this indicate some problem in 
> initial negociation and a drop back to nfs2 ?
> 
> /dev/root on / type nfs 
> (rw,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nointr,nolock,proto=udp,timeo=11,retrans=3,sec=sys,addr=192.168.1.3) 

I believe that nfsroot always defaults to vers=2 and udp unless you
explicitly set the 'nfsvers=3' and 'proto=tcp' mount options.

It also defaults to 4k rsize and wsize (set 'rsize=0,wsize=0' if you
want the client to autonegotiate their values)...

Cheers
  Trond

Re: nfs + Reiser4

[gg-B3jsHfKwJfLR7s880joybQ]

On 04/08/10 23:33, Trond Myklebust wrote:
> On Thu, 2010-04-08 at 23:03 +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote:
>> OK , I just tried this on ext3 partition and I'm not seeing the erratic
>> behaviour.  So this may be down to a bad reaction between nfs and R4 as
>> I suspected.
>>
>> However, I am still seeing vers=2 , does this indicate some problem in
>> initial negociation and a drop back to nfs2 ?
>>
>> /dev/root on / type nfs
>> (rw,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nointr,nolock,proto=udp,timeo=11,retrans=3,sec=sys,addr=192.168.1.3)
>
> I believe that nfsroot always defaults to vers=2 and udp unless you
> explicitly set the 'nfsvers=3' and 'proto=tcp' mount options.
>
> It also defaults to 4k rsize and wsize (set 'rsize=0,wsize=0' if you
> want the client to autonegotiate their values)...
>
> Cheers
>    Trond
>
>
Thanks,

I was refering to man nfs which states that nfs will always try nfs3 and 
if it fails falls back to ver 2. Maybe man nfs is not the definitive 
reference for what is in the kernel if this has changed recently.

I've pretty much concluded the main issues very nfs not playing well 
with reiser4. The doc suggests this is a gray area and indeed it seems 
to be pretty much untested since this kind of grossly bad behavious 
would not be missed.

I had some anomalies  circa 2.6.20 that were less severe but the current 
state of play is frankly pretty unusable.

Since there seems to be an implied policy of not testing with any fs not 
in mainline kernel I'll just have to copy the nfs structure to an ext3 
partition.

Thanks for you comments and help.

regards.

Re: nfs + Reiser4

[Trond Myklebust]

On Fri, 2010-04-09 at 14:09 +0200, gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org wrote: 
> I was refering to man nfs which states that nfs will always try nfs3 and 
> if it fails falls back to ver 2. Maybe man nfs is not the definitive 
> reference for what is in the kernel if this has changed recently.

The above is true for the ordinary 'mount' program, but is not true of
nfsroot.

The fallback policy for mount is now managed entirely in userspace, and
in recent versions of nfs-utils, you can configure whether you want
nfsv4, nfsv3 or nfsv2 to be the default.

Cheers
  Trond

Re: nfs + Reiser4

[J. Bruce Fields]

On Thu, Apr 08, 2010 at 12:44:38AM +0200, Bernd Schubert wrote:
> On Tuesday 06 April 2010, gg@catking.net wrote:
> > Hi,
> > 
> > I am having serious headaches using nfs between a reiser4 server and arm
> > client.
> > Both on 2.6.29 vintage kernels.
> > 
> > Files are constantly getting out of sync.
> > 
> > Example :
> > 
> > boot ARM via nfs
> > edit lighttpd.conf on ARM
> > check edit is visible on server. OK
> > 
> > reboot ARM
> > check file : reverted to an earlier state.
> > check server: edited version still showing.
> > 
> > 
> > This is just one example of serious userablity issues. I have also seen a
> > revert 10s later reopening the same file on the ARM.
> > 
> > Is this possibly related to R4 + nfs ?
> 
> Reminds me about an old bug report I wrote and which nobody ever cared about:
> 
> http://article.gmane.org/gmane.linux.nfs/9867/match=

On a possibly-too-quick skim, I think this could be explained by just
stale cache data, possibly the result of poor ext3 time resolution.
(Still a bug of some kind, but not as bizarre as the bug reported here.)

--b.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@lists.sourceforge.net is being discontinued.
Please subscribe to linux-nfs@vger.kernel.org instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs