From: Kasparek Tomas <kasparek@fit.vutbr.cz>
Subject: Re: NFS corruption in 2.6.18.2?
Date: Tue, 12 Dec 2006 14:45:01 +0100
Message-ID: <20061212134501.GK39055@fit.vutbr.cz>
References: <50e235a50d0f2b4fb34eed1c840565e3@swip.net>
	<20061123161738.GF40079@fit.vutbr.cz>
	<20061123172456.GG40079@fit.vutbr.cz>
	<20061123213311.GH40079@fit.vutbr.cz>
	<20061124064752.GI40079@fit.vutbr.cz>
	<1164395516.5702.53.camel@lade.trondhjem.org>
	<20061125182600.GA74811@fit.vutbr.cz>
	<1164479583.5886.4.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: nfs@lists.sourceforge.net
In-Reply-To: <1164479583.5886.4.camel@lade.trondhjem.org>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Sat, Nov 25, 2006 at 01:33:03PM -0500, Trond Myklebust wrote:
> On Sat, 2006-11-25 at 19:26 +0100, Kasparek Tomas wrote:
> > On Fri, Nov 24, 2006 at 02:11:55PM -0500, Trond Myklebust wrote:
> > > > > > On Thu, Nov 23, 2006 at 05:17:38PM +0100, Kasparek Tomas wrote:
> > > > > > Just update: 2.6.17.14 is ok
> > > > > 
> > > > > did git bisect between 2.6.17 and 2.6.18 and found that the commit is:
> > > > > 
> > > > > 44b11874ff583b6e766a05856b04f3c492c32b84
> > > > >  NFS: Separate metadata and page cache revalidation mechanisms
> > > > > 
> > > > > will verify (with and without patch) tomorrow.
> > > > 
> > > > 2.6.18.3 with reversed 44b11874ff583b6e766a05856b04f3c492c32b84 is OK.
> > > > 
> > > > exact patch used included.
> > > 
> > > If you are not using any form of synchronisation, then your test would
> > > appear to be violating the close-to-open cache consistency rules (see
> > > http://nfs.sourceforge.net/#faq_a8).
> > 
> > Yes, I understand this, but with no synchronization I should get old or
> > somewhat 'not current' data at worst, I don't expect to get some data
> > generated by the kernel. The test is synthetic, it was constructed to be
> > as easy as possible, but this one works well on 2.6.16 (mean no zeros, data
> > are sometimes overwriten or mixed from several clients as a result of no
> > locking, but that's ok for my application).
> 
> No. Extending the file on the server while your client has pending
> background writes can result in exactly the behaviour that you're
> observing.

Hi, still me with the same problem, sorry for being pain in the ass, but I
need to solve it somehow (being not able to change the applications used).

I have tried mounting the share with 'noac' option as mentioned in the FAQ,
but the behaviour is the same.

Would you have any other advice how to get the old behaviour (for me that
means that of kernel 2.6.16.x)?

(I tested some newer kernels to - 2.6.18.5 and 19.1 just for the case
someting changes but no success there.)

Regards.

--   

  Tomas Kasparek, PhD student  E-mail: kasparek@fit.vutbr.cz
  CVT FIT VUT Brno, BI/140a    Web:    http://www.fit.vutbr.cz/~kasparek
  Bozetechova 2, 612 66        Fax:    +420 54114-1270
  Brno, Czech Republic         Phone:  +420 54114-1220

  ICQ: 293092805  jabber: tomas.kasparek@jabber.cz
  GPG: 2F1E 1AAF FD3B CFA3 1537  63BD DCBE 18FF A035 53BC


-------------------------------------------------------------------------
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