From: Chris Mason <chris.mason@oracle.com>
To: Jacek Luczak <difrost.kernel@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>,
linux-ext4@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-btrfs@vger.kernel.org, lczerner@redhat.com
Subject: Re: getdents - ext4 vs btrfs performance
Date: Thu, 1 Mar 2012 09:51:55 -0500 [thread overview]
Message-ID: <20120301145155.GY5054@shiny> (raw)
In-Reply-To: <CADDYkjRs934T2D7DPCk_dcrazptWtLu70=A61R32p22Ee1iXsw@mail.gmail.com>
On Thu, Mar 01, 2012 at 03:43:41PM +0100, Jacek Luczak wrote:
> 2012/3/1 Chris Mason <chris.mason@oracle.com>:
> > XFS will probably beat btrfs in this test. =A0Their directory index=
es
> > reflect on disk layout very well.
>=20
> True, but not that fast on small files.
>=20
> Except the question I've raised in first mail there's a point in all
> those action. We are maintaining host that are used for building
> software: random access, lot of small files and dirs (always a co),
> heavy parallel IO. We were testing XFS vs ext4 a year ago and XFS was
> around 10% slower on build times. We did not - yet - done same on
> btrfs. Now we're looking for replacement for ext4 as we suffer from
> those issue - but we were not aware of that until stepped into this
> issue.
>=20
> If you would like me to do some specific tests around ext4 and btrfs,
> let me know.
I'm always curious to see comparisons in real world workloads. You
should definitely consider testing XFS again, the big three filesystems
are under pretty constant improvement. For btrfs, please stick to 3.2
kernels and higher.
This seeky backup performance is somewhat built into ext4, but as Ted
said there are a few workarounds.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Chris Mason <chris.mason@oracle.com>
To: Jacek Luczak <difrost.kernel@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>,
linux-ext4@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-btrfs@vger.kernel.org, lczerner@redhat.com
Subject: Re: getdents - ext4 vs btrfs performance
Date: Thu, 1 Mar 2012 09:51:55 -0500 [thread overview]
Message-ID: <20120301145155.GY5054@shiny> (raw)
In-Reply-To: <CADDYkjRs934T2D7DPCk_dcrazptWtLu70=A61R32p22Ee1iXsw@mail.gmail.com>
On Thu, Mar 01, 2012 at 03:43:41PM +0100, Jacek Luczak wrote:
> 2012/3/1 Chris Mason <chris.mason@oracle.com>:
> > XFS will probably beat btrfs in this test. Their directory indexes
> > reflect on disk layout very well.
>
> True, but not that fast on small files.
>
> Except the question I've raised in first mail there's a point in all
> those action. We are maintaining host that are used for building
> software: random access, lot of small files and dirs (always a co),
> heavy parallel IO. We were testing XFS vs ext4 a year ago and XFS was
> around 10% slower on build times. We did not - yet - done same on
> btrfs. Now we're looking for replacement for ext4 as we suffer from
> those issue - but we were not aware of that until stepped into this
> issue.
>
> If you would like me to do some specific tests around ext4 and btrfs,
> let me know.
I'm always curious to see comparisons in real world workloads. You
should definitely consider testing XFS again, the big three filesystems
are under pretty constant improvement. For btrfs, please stick to 3.2
kernels and higher.
This seeky backup performance is somewhat built into ext4, but as Ted
said there are a few workarounds.
-chris
WARNING: multiple messages have this Message-ID (diff)
From: Chris Mason <chris.mason@oracle.com>
To: Jacek Luczak <difrost.kernel@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>,
linux-ext4@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-btrfs@vger.kernel.org, lczerner@redhat.com
Subject: Re: getdents - ext4 vs btrfs performance
Date: Thu, 1 Mar 2012 09:51:55 -0500 [thread overview]
Message-ID: <20120301145155.GY5054@shiny> (raw)
In-Reply-To: <CADDYkjRs934T2D7DPCk_dcrazptWtLu70=A61R32p22Ee1iXsw@mail.gmail.com>
On Thu, Mar 01, 2012 at 03:43:41PM +0100, Jacek Luczak wrote:
> 2012/3/1 Chris Mason <chris.mason@oracle.com>:
> > XFS will probably beat btrfs in this test. Their directory indexes
> > reflect on disk layout very well.
>
> True, but not that fast on small files.
>
> Except the question I've raised in first mail there's a point in all
> those action. We are maintaining host that are used for building
> software: random access, lot of small files and dirs (always a co),
> heavy parallel IO. We were testing XFS vs ext4 a year ago and XFS was
> around 10% slower on build times. We did not - yet - done same on
> btrfs. Now we're looking for replacement for ext4 as we suffer from
> those issue - but we were not aware of that until stepped into this
> issue.
>
> If you would like me to do some specific tests around ext4 and btrfs,
> let me know.
I'm always curious to see comparisons in real world workloads. You
should definitely consider testing XFS again, the big three filesystems
are under pretty constant improvement. For btrfs, please stick to 3.2
kernels and higher.
This seeky backup performance is somewhat built into ext4, but as Ted
said there are a few workarounds.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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:[~2012-03-01 14:51 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 13:52 getdents - ext4 vs btrfs performance Jacek Luczak
2012-02-29 13:55 ` Jacek Luczak
2012-02-29 13:55 ` Jacek Luczak
2012-02-29 14:07 ` Jacek Luczak
2012-02-29 14:07 ` Jacek Luczak
2012-02-29 14:07 ` Jacek Luczak
2012-02-29 14:21 ` Jacek Luczak
2012-02-29 14:21 ` Jacek Luczak
2012-02-29 14:21 ` Jacek Luczak
2012-02-29 14:42 ` Chris Mason
2012-02-29 14:55 ` Jacek Luczak
2012-03-01 13:35 ` Jacek Luczak
2012-03-01 13:50 ` Hillf Danton
2012-03-01 14:03 ` Jacek Luczak
2012-03-01 14:18 ` Chris Mason
2012-03-01 14:43 ` Jacek Luczak
2012-03-01 14:43 ` Jacek Luczak
2012-03-01 14:51 ` Chris Mason [this message]
2012-03-01 14:51 ` Chris Mason
2012-03-01 14:51 ` Chris Mason
2012-03-01 14:57 ` Jacek Luczak
2012-03-01 14:57 ` Jacek Luczak
2012-03-01 14:57 ` Jacek Luczak
2012-03-01 18:42 ` Ted Ts'o
2012-03-02 9:51 ` Jacek Luczak
2012-03-01 4:44 ` Theodore Tso
2012-03-01 4:44 ` Theodore Tso
2012-03-01 4:44 ` Theodore Tso
2012-03-01 14:38 ` Chris Mason
2012-03-01 14:38 ` Chris Mason
2012-03-02 10:05 ` Jacek Luczak
2012-03-02 10:05 ` Jacek Luczak
2012-03-02 10:05 ` Jacek Luczak
2012-03-02 14:00 ` Chris Mason
2012-03-02 14:16 ` Jacek Luczak
2012-03-02 14:16 ` Jacek Luczak
2012-03-02 14:16 ` Jacek Luczak
2012-03-02 14:26 ` Chris Mason
2012-03-02 14:26 ` Chris Mason
2012-03-02 19:32 ` Ted Ts'o
2012-03-02 19:50 ` Chris Mason
2012-03-05 13:10 ` Jan Kara
2012-03-03 22:41 ` Jacek Luczak
2012-03-03 22:41 ` Jacek Luczak
2012-03-04 10:25 ` Jacek Luczak
2012-03-04 10:25 ` Jacek Luczak
2012-03-05 11:32 ` Jacek Luczak
2012-03-05 11:32 ` Jacek Luczak
2012-03-05 11:32 ` Jacek Luczak
2012-03-06 0:37 ` Chris Mason
2012-03-06 0:37 ` Chris Mason
2012-03-08 17:02 ` Phillip Susi
2012-03-09 11:29 ` Lukas Czerner
2012-03-09 14:34 ` Chris Mason
2012-03-10 0:09 ` Andreas Dilger
2012-03-10 4:48 ` Ted Ts'o
2012-03-11 10:30 ` Andreas Dilger
2012-03-11 16:13 ` Ted Ts'o
2012-03-15 10:42 ` Jacek Luczak
2012-03-15 10:42 ` Jacek Luczak
2012-03-15 10:42 ` Jacek Luczak
2012-03-18 20:56 ` Ted Ts'o
2012-03-13 19:05 ` Phillip Susi
2012-03-13 19:53 ` Ted Ts'o
2012-03-13 20:22 ` Phillip Susi
2012-03-13 21:33 ` Ted Ts'o
2012-03-14 2:48 ` Yongqiang Yang
2012-03-14 2:51 ` Ted Ts'o
2012-03-14 14:17 ` Zach Brown
2012-03-14 16:48 ` Ted Ts'o
2012-03-14 17:37 ` Zach Brown
2012-03-14 8:12 ` Lukas Czerner
2012-03-14 9:29 ` Yongqiang Yang
2012-03-14 9:29 ` Yongqiang Yang
2012-03-14 9:29 ` Yongqiang Yang
2012-03-14 9:38 ` Lukas Czerner
2012-03-14 12:50 ` Ted Ts'o
2012-03-14 14:34 ` Lukas Czerner
2012-03-14 17:02 ` Ted Ts'o
2012-03-14 19:17 ` Chris Mason
2012-03-14 14:28 ` Phillip Susi
2012-03-14 16:54 ` Ted Ts'o
2012-03-10 3:52 ` Ted Ts'o
2012-03-15 7:59 ` Jacek Luczak
2012-03-15 7:59 ` Jacek Luczak
2012-03-15 7:59 ` Jacek Luczak
-- strict thread matches above, loose matches on Subject: below --
2012-02-29 13:31 Jacek Luczak
2012-02-29 13:51 ` Chris Mason
2012-02-29 14:00 ` Lukas Czerner
2012-02-29 14:05 ` Chris Mason
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=20120301145155.GY5054@shiny \
--to=chris.mason@oracle.com \
--cc=dhillf@gmail.com \
--cc=difrost.kernel@gmail.com \
--cc=lczerner@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.