From: Chris Mason <chris.mason@oracle.com>
To: David Chinner <dgc@sgi.com>
Cc: "Cabot, Mason B" <mason.b.cabot@intel.com>, linux-kernel@vger.kernel.org
Subject: Re: Ext3 vs NTFS performance
Date: Wed, 2 May 2007 15:46:21 -0400 [thread overview]
Message-ID: <20070502194621.GY1518@think.oraclecorp.com> (raw)
In-Reply-To: <20070502154414.GB77450368@melbourne.sgi.com>
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
next prev parent reply other threads:[~2007-05-02 20:36 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 20:43 Ext3 vs NTFS performance Cabot, Mason B
2007-05-01 21:23 ` Andrew Morton
2007-05-02 12:21 ` Andi Kleen
2007-05-02 16:04 ` Theodore Tso
2007-05-02 18:40 ` Andi Kleen
2007-05-02 19:28 ` Theodore Tso
2007-05-02 16:16 ` Theodore Tso
2007-05-02 18:08 ` Jeremy Allison
2007-05-02 19:34 ` Theodore Tso
2007-05-02 20:38 ` Jeff Garzik
2007-05-02 22:01 ` Theodore Tso
2007-05-02 3:54 ` Gerhard Mack
2007-05-02 15:46 ` David Chinner
2007-05-02 15:44 ` David Chinner
2007-05-02 19:46 ` Chris Mason [this message]
2007-05-03 0:15 ` David Chinner
2007-05-03 12:57 ` Chris Mason
2007-05-03 21:14 ` Valerie Henson
2007-05-03 22:40 ` Bernd Eckenfels
2007-05-04 8:12 ` Anton Altaparmakov
2007-05-04 9:46 ` Christoph Hellwig
2007-05-04 14:47 ` Anton Altaparmakov
2007-05-04 15:49 ` Michael Tokarev
2007-05-04 18:41 ` Theodore Tso
2007-05-05 9:59 ` Christoph Hellwig
2007-05-06 20:59 ` Jörn Engel
2007-05-04 12:23 ` Theodore Tso
2007-05-04 19:40 ` Valerie Henson
2007-05-04 18:56 ` Phillip Susi
2007-05-04 19:52 ` Cabot, Mason B
2007-05-07 14:31 ` Phillip Susi
2007-09-12 23:47 ` Update: " Cabot, Mason B
-- strict thread matches above, loose matches on Subject: below --
2007-05-03 3:51 Al Boldi
2007-05-05 3:13 Xu CanHao
2007-05-05 13:45 ` Theodore Tso
[not found] <8hiYr-2fJ-1@gated-at.bofh.it>
[not found] ` <8huGm-2W4-33@gated-at.bofh.it>
2007-05-05 22:25 ` Bodo Eggert
2007-05-06 5:04 ` Xu CanHao
2007-05-06 1:48 Albert Cahalan
[not found] <8gShI-3hY-11@gated-at.bofh.it>
[not found] ` <8h1bh-8sG-11@gated-at.bofh.it>
[not found] ` <8h2Al-280-1@gated-at.bofh.it>
[not found] ` <8hW9y-2Lp-3@gated-at.bofh.it>
2007-05-07 11:21 ` Bodo Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070502194621.GY1518@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=dgc@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mason.b.cabot@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox