From: Zack Coffey <clickwir@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-raid@vger.kernel.org, linux-mm@kvack.org
Subject: Re: ext4 vs btrfs performance on SSD array
Date: Tue, 2 Sep 2014 08:55:07 -0400 [thread overview]
Message-ID: <CAA8KC9Lgjf_FBXnKAaJtp6=NCWsoCFOobgi5b84BXfAcbgynJQ@mail.gmail.com> (raw)
In-Reply-To: <20140902012222.GA21405@infradead.org>
While I'm sure some of those settings were selected with good reason,
maybe there can be a few options (2 or 3) that have some basic
intelligence at creation to pick a more sane option.
Some checks to see if an option or two might be better suited for the
fs. Like the RAID5 stripe size. Leave the default as is, but maybe a
quick speed test to automatically choose from a handful of the most
common values. If they fail or nothing better is found, then apply the
default value just like it would now.
On Mon, Sep 1, 2014 at 9:22 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Sep 02, 2014 at 10:08:22AM +1000, Dave Chinner wrote:
>> Pretty obvious difference: avgrq-sz. btrfs is doing 512k IOs, ext4
>> and XFS are doing is doing 128k IOs because that's the default block
>> device readahead size. 'blockdev --setra 1024 /dev/sdd' before
>> mounting the filesystem will probably fix it.
>
> Btw, it's really getting time to make Linux storage fs work out the
> box. There's way to many things that are stupid by default and we
> require everyone to fix up manually:
>
> - the ridiculously low max_sectors default
> - the very small max readahead size
> - replacing cfq with deadline (or noop)
> - the too small RAID5 stripe cache size
>
> and probably a few I forgot about. It's time to make things perform
> well out of the box..
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-09-02 12:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 23:39 ext4 vs btrfs performance on SSD array Nikolai Grigoriev
2014-08-27 7:10 ` Duncan
2014-08-27 21:59 ` Nikolai Grigoriev
2014-09-02 0:08 ` Dave Chinner
2014-09-02 1:22 ` Christoph Hellwig
2014-09-02 11:31 ` Theodore Ts'o
2014-09-02 14:20 ` Jan Kara
2014-09-02 14:55 ` Theodore Ts'o
2014-09-02 12:55 ` Zack Coffey [this message]
2014-09-02 13:40 ` Austin S Hemmelgarn
2014-09-03 0:01 ` NeilBrown
2014-09-05 16:08 ` Christoph Hellwig
2014-09-05 16:40 ` Jeff Moyer
2014-09-05 16:50 ` Jens Axboe
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='CAA8KC9Lgjf_FBXnKAaJtp6=NCWsoCFOobgi5b84BXfAcbgynJQ@mail.gmail.com' \
--to=clickwir@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-raid@vger.kernel.org \
/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).