Re: nfs + Reiser4

[gg-B3jsHfKwJfLR7s880joybQ@public.gmane.org]

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.