From: Ric Wheeler <ricwheeler@gmail.com>
To: Theodore Tso <tytso@mit.edu>, Ric Wheeler <rwheeler@redhat.com>,
Jens Axboe <jens.axboe@oracle.com>,
Mikulas Patocka <mpatocka@redhat.com>,
device-mapper development <dm-devel@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ak@linux.intel.com, "MASON, CHRISTOPHER" <CHRIS.MASON@oracle.com>
Subject: Re: [dm-devel] Barriers still not passing on simple dm devices...
Date: Sun, 05 Apr 2009 04:54:46 -0700 [thread overview]
Message-ID: <49D89C06.1060700@gmail.com> (raw)
In-Reply-To: <20090405012839.GF7553@mit.edu>
On 04/04/2009 06:28 PM, Theodore Tso wrote:
> On Sat, Apr 04, 2009 at 11:20:35AM -0400, Ric Wheeler wrote:
>
>> Barriers do work as we have them, but as others have mentioned, it is
>> not a "free" win - fsync will actually move your data safely out to
>> persistent storage for a huge percentage of real users (including every
>> ATA/S-ATA and SAS drive I was able to test). The file systems I
>> monitored in production use without barriers were much less reliable.
>>
>
> The problem is that, as long as you're not under memory pressure, and
> not pushing the filesystem heavily, ext3 didn't corrupt *that* often
> without barriers. So people got away with it "most of the time" ---
> just as applications replacing files by rewriting them in place using
> truncate and w/o fsync would "usually" not lose data after a crash if
> they were using ext3 with data=ordered mode. This caused people to
> get lazy/sloppy.
>
> So yes, barriers were something that were largely ignored for a long
> time. After all, in a server environment with UPS's, without crappy
> proprietary video drivers, Linux systems didn't crash that often
> anyway. So you really needed a large base of systems and with the
> ability to root cause failures such as what Ric had at EMC to see the
> problem.
>
One thing to point out here is that there are a lot of "servers" in high
end data centers that do not have UPS backup. Those racks full of 1U and
2U boxes that are used to make "grids", "clouds" and so on often are
built with as much gear as you can stuff in a rack - no batteries or UPS
to be seen, so they are really quite similar to the normal desktop or
home systems that we normally run at home :-)
ric
> Even now, the reason why ext3 doesn't have barriers enabled by default
> (although we did make them the default for ext4) is because Andrew
> doesn't believe Chris's replication case is likely to be true for most
> users in practice, and he's concerned about the performance
> degradation of barriers. He's basically depending on the fact that
> "usually" you can get away without using barriers. Sigh....
>
> - Ted
>
> P.S. Of course, distributions should feel free to consider changing
> the default on their kernels. SLES has already if memory serves
> correctly. I don't know if RHEL has yet.
>
>
>
next prev parent reply other threads:[~2009-04-05 11:55 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-23 19:04 Barriers still not passing on simple dm devices Eric Sandeen
2009-03-23 19:10 ` Eric Sandeen
2009-03-24 14:02 ` [dm-devel] " Mikulas Patocka
2009-03-24 14:05 ` Jens Axboe
2009-03-24 14:26 ` Mikulas Patocka
2009-03-24 14:30 ` Jens Axboe
2009-03-24 14:45 ` Mikulas Patocka
2009-03-24 15:05 ` Jens Axboe
2009-03-25 15:15 ` Mikulas Patocka
2009-03-25 15:27 ` Jens Axboe
2009-03-25 22:39 ` Mikulas Patocka
2009-03-26 8:42 ` Jens Axboe
2009-03-31 3:39 ` Mikulas Patocka
2009-03-31 10:49 ` Jens Axboe
2009-04-02 23:40 ` Mikulas Patocka
2009-04-03 8:11 ` Jens Axboe
2009-04-04 15:20 ` Ric Wheeler
2009-04-05 1:28 ` Theodore Tso
2009-04-05 11:54 ` Ric Wheeler [this message]
2009-04-06 1:14 ` Lee Revell
2009-04-06 1:24 ` Ric Wheeler
2009-04-08 12:44 ` Mikulas Patocka
2009-04-08 15:16 ` Henrique de Moraes Holschuh
2009-04-09 4:22 ` Eric Sandeen
2009-04-08 12:36 ` Mikulas Patocka
2009-04-08 12:54 ` Mikulas Patocka
2009-04-09 10:48 ` Ric Wheeler
2009-04-08 13:37 ` Mikulas Patocka
2009-04-08 14:06 ` Jens Axboe
2009-04-08 23:44 ` Dave Chinner
2009-04-09 1:27 ` Chris Mason
2009-04-09 10:28 ` Alasdair G Kergon
2009-03-26 12:55 ` Chris Mason
[not found] <ciXHh-39c-37@gated-at.bofh.it>
[not found] ` <cjfuL-6vJ-43@gated-at.bofh.it>
[not found] ` <cjfEl-6J2-45@gated-at.bofh.it>
[not found] ` <cjfNX-6Wh-27@gated-at.bofh.it>
2009-03-26 13:05 ` Bodo Eggert
[not found] ` <cjfXx-78D-9@gated-at.bofh.it>
[not found] ` <cjg7h-7lM-29@gated-at.bofh.it>
[not found] ` <cjgqC-80G-21@gated-at.bofh.it>
[not found] ` <cjD3I-22U-7@gated-at.bofh.it>
[not found] ` <cjDdE-2g3-31@gated-at.bofh.it>
[not found] ` <cjJVv-4vp-13@gated-at.bofh.it>
[not found] ` <cjXlS-uM-1@gated-at.bofh.it>
2009-03-26 15:26 ` 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=49D89C06.1060700@gmail.com \
--to=ricwheeler@gmail.com \
--cc=CHRIS.MASON@oracle.com \
--cc=ak@linux.intel.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=rwheeler@redhat.com \
--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