Strange NFS behaviour

Strange NFS behaviour

[Simone Carbonara]

Hello,

i'm experiencing on debian etch the following behaviour with NFS.

I have 1 backend running linux debian sarge that exports via NFS a  SVN 
working copy to a couple of frontend (debian etch) that read the 
contents of the exported NFS share called /WEB-2 (under drbd ) and 
publish it via apache.

Sometimes when i update my working copy on my backend i don't see the 
changes on all the frontends as follows the output on ls on the frontends.

FE-01:~# ls -alio /WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php
17237334 -rw-r----- 0 vapache 3387 2008-05-16 11:10 
/WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php
FE-02:~# ls -alio /WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php
17237564 -rw-r--r-- 1 vapache 3801 2008-05-23 11:09 
/WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php


If i remount the /WEB-1 share on the frontend the changes are seen and 
updated correctly on all frontends but it's clear that this behaviour is 
not accetable when writing codes that needs to be updated directly on 
production.

The exportfs flag options on the exported fs on the Backend are as follows

rw,all_squash,anonuid=4001,anongid=555,no_subtree_check,sync.

Someone could address me in any troubleshooting steps on this issue?

Best Regards,

Simone Carbonara

Re: Strange NFS behaviour

[david m. richter]

On Fri, 23 May 2008, Simone Carbonara wrote:

> Hello,
> 
> i'm experiencing on debian etch the following behaviour with NFS.
> 
> I have 1 backend running linux debian sarge that exports via NFS a  SVN
> working copy to a couple of frontend (debian etch) that read the contents of
> the exported NFS share called /WEB-2 (under drbd ) and publish it via apache.
> 
> Sometimes when i update my working copy on my backend i don't see the changes
> on all the frontends as follows the output on ls on the frontends.
> 
> FE-01:~# ls -alio /WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php
> 17237334 -rw-r----- 0 vapache 3387 2008-05-16 11:10
> /WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php
> FE-02:~# ls -alio /WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php
> 17237564 -rw-r--r-- 1 vapache 3801 2008-05-23 11:09
> /WEB-2/sites/http/pilot/frontend/contenuto_lista_nozze.php
> 
> 
> If i remount the /WEB-1 share on the frontend the changes are seen and updated
> correctly on all frontends but it's clear that this behaviour is not accetable
> when writing codes that needs to be updated directly on production.

	it's the client-side caching.  i used to run into essentially the 
same thing when developing on a git repository that's exported over NFSv4, 
then mounting and building on the clients (with lndir or make O=) -- i'll 
quick fix a little bug and try to recompile, but the clients don't notice 
the change until their caches expire or they're forced to invalidate them 
(say, touch the changed file, but that's lame).

	you can experiment with mount options like 'noac' or 'actimeo' 
(see the nfs(5) manpage); they'll impact performance somewhat, but maybe 
in your situation it won't be a problem.

	good luck,

	d
	.

> 
> The exportfs flag options on the exported fs on the Backend are as follows
> 
> rw,all_squash,anonuid=4001,anongid=555,no_subtree_check,sync.
> 
> Someone could address me in any troubleshooting steps on this issue?
> 
> Best Regards,
> 
> Simone Carbonara
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Strange NFS behaviour

[Simone Carbonara]

Thank you David for the reply.

> 	it's the client-side caching.  i used to run into essentially the 
> same thing when developing on a git repository that's exported over NFSv4, 
> then mounting and building on the clients (with lndir or make O=) -- i'll 
> quick fix a little bug and try to recompile, but the clients don't notice 
> the change until their caches expire or they're forced to invalidate them 
> (say, touch the changed file, but that's lame).

That's sounds like the same behaviour. But what i noticed is that .svn 
dir of the repository is correctly updated while the file remains in 
this 0 state. Did you see the 0 after the permission fields? I've never 
experiencing such output.

> 	you can experiment with mount options like 'noac' or 'actimeo' 
> (see the nfs(5) manpage); they'll impact performance somewhat, but maybe 
> in your situation it won't be a problem.
> 

I've added the noac option just last monday but it didn't fix the 
problem. I'll try actimeo flag and give you a feedback. I don't care 
about the performance lately i just need my customer see the changes on 
the svn repos exported :-).

Thanks a lot.

simone