lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080911184951.GB19054@merfinllc.com>
Date:	Thu, 11 Sep 2008 11:49:52 -0700
From:	Aaron Straus <aaron@...finllc.com>
To:	Chuck Lever <chuck.lever@...cle.com>
Cc:	Neil Brown <neilb@...e.de>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	LKML Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20

Hi,

On Sep 11 01:48 PM, Chuck Lever wrote:
> Were you able to modify your writer to do real fsync system calls?  If  
> so, did it help?  That would be a useful data point.

Yes/Yes.  Please see the attached tarball sync-test.tar.bz2.

Inside you'll find the modified writer:  writer_sync.py

That will call fsync on the file descriptor after each write.

Also I added the strace and wireshark data for the sync and nosync
cases.

Note these are all tested with latest linus git:  

  d1c6d2e547148c5aa0c0a4ff6aac82f7c6da1d8b

> Practically speaking this is often not enough for typical  
> applications, so NFS client implementations go to further (non- 
> standard) efforts to behave like a local file system.  This is simply  
> a question of whether we can address this while not creating  
> performance or correctness issues for other common use cases.

Yep, I agree.  I'm not saying what we do now is "wrong" per the RFC
(writing the file out of order).  It's just different from what we've
done in the past (and somewhat unexpected).

I'm still hoping there is a simple fix... but maybe not... :(

Thanks!

					=a=

-- 
===================
Aaron Straus
aaron@...finllc.com

Download attachment "sync-test.tar.bz2" of type "application/octet-stream" (15200 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ