From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Hendrik Friedel <hendrik@friedels.name>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs and write barriers
Date: Tue, 2 Apr 2019 07:46:41 -0400 [thread overview]
Message-ID: <2756c52f-eca4-7a26-aec7-46256ca1bdcb@gmail.com> (raw)
In-Reply-To: <emae84cb43-e9f5-41a7-8a47-efca08cea36e@laptophendrik>
On 2019-04-01 15:22, Hendrik Friedel wrote:
> Dear btrfs-team,
>
> I am aware, that barriers are essential for btrfs [1].
> I have some questions on that topic:
> 1) I am not aware how to determine, whether barriers are supported,
> except for searching dmesg for a message that barriers are disabled. Is
> that correct? It would be nice, if that could be determined before
> creating the FS.
AFAIK, this is correct. However, not supporting DPO or FUA is
non-critical, because the kernel emulates them properly (there would be
many problems far beyond BTRFS if it didn't, as most manufacturers treat
FUA the same way they treat SCT ERC, it's an 'enterprise' feature, so
consumers aren't allowed to have it).
> 2) I find the location of the (only?) warning -dmesg- well hidden. I
> think it would be better to notify the user when creating the file-system.
A notification on creating the volume and ones when adding devices
(either via `device add` or via a replace operation) would indeed be
nice, but we should still keep the kernel log warning. Note also that
messages like what Qu mentioned as being fine are from the SCSI layer
(yes, even if you're using ATA or USB disks, they both go through the
SCSI layer in Linux), not BTRFS.
> 3) Even more, it would be good, if btrfs would disable the write cache
> in that case, so that one does not need to rely on the user
I would tend to disagree here. We should definitely _recommend_ this to
the user if we know there is no barrier support, but just doing it
behind their back is not a good idea. There are also plenty of valid
reasons to want to use the write cache anyway.
> 4) If [2] is still valid, there are drives 'lying' about their barrier
> support. Can someone comment? If that is the case, it would be even
> advisable to provide a test to test the actual capability. In fact, if
> this is still valid, this may be the reason for some btrfs corruptions
> that have been discussed here. [I did read, that LVM/Device-Mapper does
> not support barriers, but I think that this is outdated]There are two things to consider here, the FLUSH command which is
mandatory as per SCSI, ATA, and pretty much every other storage protocol
specification, and FUA/DPO, which is not. If you have FLUSH, you can
emulate FUA/DPO.
The only modern devices I know of that actually _lied_ about FLUSH are
OCZ SSD's. They've stopped making them because the associated data-loss
issues killed any consumer trust in the product. The only other devices
I've ever seen _any_ issue with the FLUSH implementation in are some
ancient SCSI-2 5.25 inch full height disk drives where I work, which
have a firmware bug that reports the FLUSH completed before the last
sector in the write cache is written out (they still write that last
sector, they just report command completion early).
As far as FUA/DPO, I know of exactly _zero_ devices that lie about
implementing it and don't. Unlike FLUSH, which is a required part of
almost all modern storage protocols, FUA/DPO isn't required, so there's
essentially zero incentive to claim you implement it when you don't
(people who would be looking for it generally will know what they're doing
As far as that article you're linking about disks lying, note first that
it's just over 14 years old (that's almost three times the MTBF for
normal hard drives), and much has changed since then. The actual issue
there is not the disks doing write caching (which is what is actually
being complained about), but the fact that Linux used to not issue a
FLUSH command to the disks when you called fsync in userspace.
>
> Greetings,
> Hendrik
>
>
> [1]
> https://btrfs.wiki.kernel.org/index.php/FAQ#I_see_a_warning_in_dmesg_about_barriers_being_disabled_when_mounting_my_filesystem._What_does_that_mean.3F
>
> [2] https://brad.livejournal.com/2116715.html
>
prev parent reply other threads:[~2019-04-02 11:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 19:22 btrfs and write barriers Hendrik Friedel
2019-04-02 0:13 ` Qu Wenruo
[not found] ` <em07dd5637-7710-4eaa-8659-8d8eef1fc709@ryzen>
2019-04-03 18:44 ` Austin S. Hemmelgarn
2019-04-28 19:27 ` Re[2]: " Hendrik Friedel
2019-04-28 23:53 ` Qu Wenruo
[not found] ` <eme2e3d545-ea78-4120-9800-6a33db6c506b@ryzen>
2019-04-03 19:38 ` Re[3]: " Hendrik Friedel
2019-04-04 1:00 ` Qu Wenruo
2019-04-02 11:46 ` Austin S. Hemmelgarn [this message]
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=2756c52f-eca4-7a26-aec7-46256ca1bdcb@gmail.com \
--to=ahferroin7@gmail.com \
--cc=hendrik@friedels.name \
--cc=linux-btrfs@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.