From: Eric Sandeen <sandeen@redhat.com>
To: tytso@mit.edu
Cc: Daniel Taylor <Daniel.Taylor@wdc.com>,
amir73il@gmail.com, linux-ext4@vger.kernel.org
Subject: Re: inconsistent file placement
Date: Tue, 06 Jul 2010 18:39:07 -0500 [thread overview]
Message-ID: <4C33BE9B.4010402@redhat.com> (raw)
In-Reply-To: <20100706231412.GA7646@thunk.org>
tytso@mit.edu wrote:
> On Tue, Jul 06, 2010 at 03:15:00PM -0700, Daniel Taylor wrote:
...
>
> Speaking of fallocate.... if this is a NAS box than the file is
> probably written using CIFS, right? Are you using a modern version of
> Samba? If you are use a new enough libc (that understands the
> fallocate system call) and a new enough version of Samba, the
> userspace should be using fallocate() to more efficiently allocate the
> space. This is a feature which is not in ext3, but it is supported by
> ext4, and it's a major win. The basic idea was discovered a while
> ago, and was written up here:
>
> http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/
>
> (This was a 2007 report, and back then ext4 wasn't ready, so the only
> file system available was XFS, which did have both delayed allocation
> and fallocate support for preallocation. XFS is a good filesystem,
> although it often tends to be a bit memory-hungry for many bookshelf
> NAS systems.)
XFS is actually a favorite of the ARM embedded NAS space :)
> See also see here for a patch (but I'm pretty sure this functionality
> is already in the most recent version of Samba if I recall correctly):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=525532
that patch is rather simplistic, FWIW; at least for XFS it -hurt- perf
due to the unwritten->written conversion and the relatively small, frequent
preallocations.
More smarts to merge up multiple 1-byte-writes into a large preallocation
might help, as the bug mentions.
But ... is something like it already in samba? that'd be nifty, but I wasn't
aware of that. There is a preallocation-sounding switch but I think it doesn't
do what you think it does. I'd have to go look up details, though.
-Eric
> I know a fair number of folks on the Samba core team; most of them
> have been hired by companies to work full-time on CIFS support
> (usually using Samba), but some of them may still be available to help
> out on a consulting basis... let me know if you'd like me to make some
> introductions.
>
> - Ted
>
> P.S. Amir, this is one of the reason why you folks should seriously think
> about merging Next3 support into ext4. :-)
next prev parent reply other threads:[~2010-07-06 23:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-06 1:49 inconsistent file placement Daniel Taylor
2010-07-06 2:38 ` Eric Sandeen
2010-07-06 6:52 ` Amir G.
2010-07-06 18:55 ` tytso
2010-07-06 18:59 ` Eric Sandeen
2010-07-06 22:01 ` tytso
2010-07-06 22:15 ` Daniel Taylor
2010-07-06 23:14 ` tytso
2010-07-06 23:39 ` Eric Sandeen [this message]
2010-07-07 1:08 ` Daniel Taylor
2010-07-07 2:29 ` Eric Sandeen
2010-07-06 23:34 ` Eric Sandeen
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=4C33BE9B.4010402@redhat.com \
--to=sandeen@redhat.com \
--cc=Daniel.Taylor@wdc.com \
--cc=amir73il@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).