linux-kernel - Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20

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]

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)