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]

Message-Id: <56258A29-95D5-4A8C-A097-014B8FEDFB8F@oracle.com>
Date:	Thu, 11 Sep 2008 13:48:49 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Aaron Straus <aaron@...finllc.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

On Sep 11, 2008, at Sep 11, 2008, 1:19 PM, Aaron Straus wrote:
> Hi,
>
> On Sep 11 12:55 PM, Chuck Lever wrote:
>> A more thorough review of the NFS write and flush logic that exists  
>> in
>> 2.6.27 is needed if we choose to recognize this issue as a real
>> problem.
>
> Yep.
>
> Sorry.  I didn't mean we should revert the hunk.  I was just trying to
> help identify the cause of the new behavior.
>
> I think this is a real problem albeit not a "serious" one.  Network
> file-systems usually try to avoid readers seeing blocks of zeros in
> files, especially in this simple writer/reader case.
>
> It wouldn't be bad if the file is written out of order occasionally,  
> but
> we see this constantly now.
>
> We cannot write/read log files to NFS mounts reliably any more.  That
> seems like a valid use case which no longer works?

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.

NFS uses close-to-open cache coherency.  Thus we expect the file to be  
consistent and up to date after it is opened by a client, but not  
necessarily if some other client writes to it after it was opened.  We  
usually recommend file locking and direct I/O to minimize these  
problems.

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.

Anyway, I'm not the NFS client maintainer, so this decision is not up  
to me.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/