linux-kernel - Re: Ext3 vs NTFS performance

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: <20070502194621.GY1518@think.oraclecorp.com>
Date:	Wed, 2 May 2007 15:46:21 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	David Chinner <dgc@....com>
Cc:	"Cabot, Mason B" <mason.b.cabot@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Ext3 vs NTFS performance

On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote:
> On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
> > Hello all,
> > 
> > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> > video workloads. The Windows CIFS client will attempt a poor-man's
> > pre-allocation of the file on the server by sending 1-byte writes at
> > 128K-byte strides, breaking block allocation on ext3 and leading to
> > fragmentation and poor performance. This will happen for many
> > applications (including iTunes) as the CIFS client issues these
> > pre-allocates under the application layer.
> > 
> > I've posted a brief paper on Intel's OSS website
> > (http://softwarecommunity.intel.com/articles/eng/1259.htm). Please give
> > it a read and let me know what you think. In particular, I'd like to
> > arrive at the right place to fix this problem: is it in the filesystem,
> > VFS, or Samba?
> 
> As I commented on IRC to Val Henson - the XFS performance indicates
> that it is not a VFS or Samba problem.
> 
> I'd say it's probably delayed allocation that is making the
> difference here - no allocation occurs on the single byte writes, it
> occurs when the larger data writes are flushed to disk. Hence no
> adverse fragmentation will occur and there wil be no extra
> allocations being done.
> 
> Hence I think it's probably a filesystm problem - it would be
> interesting to see how ext4 performs on this workload....

If we rely on delalloc for this, what happens if another proc on the
same fs is doing synchronous writes to other files? (say for mail
delivery).  Will random FS commits force delayed allocations to become
real?

Also, I'd expect a sufficiently loaded server to break down eventually
as load/users increase.  The cost of a bad delalloc decision gets much
higher if we're using it as a crutch for this kind of bad userland
coding.

-chris

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