From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Cc: linux-mm@kvack.org
Subject: Re: [Bug 199931] New: systemd/rtorrent file data corruption when using echo 3 >/proc/sys/vm/drop_caches
Date: Fri, 8 Jun 2018 07:18:44 +0000 (UTC) [thread overview]
Message-ID: <pan$a2388$84c4dee0$cda57858$77256a9d@cox.net> (raw)
In-Reply-To: 20180606190635.meodcz3mchhtqprb@schmorp.de
Marc Lehmann posted on Wed, 06 Jun 2018 21:06:35 +0200 as excerpted:
> Not sure what exactly you mean with btrfs mirroring (there are many
> btrfs features this could refer to), but the closest thing to that that
> I use is dup for metadata (which is always checksummed), data is always
> single. All btrfs filesystems are on lvm (not mirrored), and most (but
> not all) are encrypted. One affected fs is on a hardware raid
> controller, one is on an ssd. I have a single btrfs fs in that box with
> raid1 for metadata, as an experiment, but I haven't used it for testing
> yet.
On the off chance, tho it doesn't sound like it from your description...
You're not doing LVM snapshots of the volumes with btrfs on them,
correct? Because btrfs depends on filesystem GUIDs being just that,
globally unique, using them to find the possible multiple devices of a
multi-device btrfs (normal single-device filesystems don't have the issue
as they don't have to deal with multi-device as btrfs does), and btrfs
can get very confused, with data-loss potential, if it sees multiple
copies of a device with the same filesystem GUID, as can happen if lvm
snapshots (which obviously have the same filesystem GUID as the original)
are taken and both the snapshot and the source are exposed to btrfs
device scan (which is auto-triggered by udev when the new device
appears), with one of them mounted.
Presumably you'd consider lvm snapshotting a form of mirroring and you've
already said you're not doing that in any form, but just in case, because
this is a rather obscure trap people using lvm could find themselves in,
without a clue as to the danger, and the resulting symptoms could be
rather hard to troubleshoot if this possibility wasn't considered.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2018-06-08 7:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-199931-27@https.bugzilla.kernel.org/>
2018-06-05 20:03 ` [Bug 199931] New: systemd/rtorrent file data corruption when using echo 3 >/proc/sys/vm/drop_caches Andrew Morton
2018-06-05 21:22 ` Tetsuo Handa
2018-06-05 21:38 ` Andrew Morton
2018-06-05 21:52 ` james harvey
2018-06-06 19:06 ` Marc Lehmann
2018-06-06 20:33 ` james harvey
2018-06-08 7:18 ` Duncan [this message]
2018-06-06 0:18 ` Chris Mason
2018-06-06 13:38 ` Liu Bo
2018-06-06 13:44 ` Chris Mason
2018-06-06 13:55 ` Liu Bo
2018-06-06 8:45 ` Michal Hocko
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='pan$a2388$84c4dee0$cda57858$77256a9d@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-mm@kvack.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).