From: Goffredo Baroncelli <kreijack@inwind.it>
To: dsterba@suse.cz
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/5] Avoid to consider lvm snapshots when scanning devices.
Date: Tue, 09 Dec 2014 19:19:00 +0100 [thread overview]
Message-ID: <54873D14.8000208@inwind.it> (raw)
In-Reply-To: <20141209102728.GA20595@twin.jikos.cz>
On 12/09/2014 11:27 AM, David Sterba wrote:
>> > Today the lvm-snapshot and btrfs behave very poor: it is not
>> > predictable which device is pick (the original or the snapshot).
>> > These patch *avoid* most problems skipping the snapshots, which
>> > to me seems a reasonable default.
>> > For the other case the user is still able to mount any disks
>> > [combination] passing them directly via command line (
>> > mount /dev/sdX -o device=/dev/sdY,device=/dev/sdz... );
> Beware that passing 'device' does not mean that btrfs will use that
> device to assemble the filesystem. It only says to scan the device the
> same way any preceding 'btrfs dev scan' would do.
I thought a bit about your sentence, but I was unable to understand
the difference. Could you describe a case where it is different ?
I have quite clear that "btrfs scan <dev>" and "mount -o device=<dev>"
do the same thing: these fill a table with the devices information
grouped by fsid. Then the kernel uses this table as hint to pick
the devices for a filesystem. So except some strange case
(like device "hot" removed) this shouldn't make any difference...
Or not ?
The point is that when a btrfs scan is ran asynchronously,
a snapshot "may" hide the origin volume. Where the word
"may" means that it is not predictable. Passing the device solve only
this point: it becomes predictable which device is used.
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2014-12-09 18:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 18:39 [PATCH V2][BTRFS-PROGS] Don't use LVM snapshot device Goffredo Baroncelli
2014-12-04 18:39 ` [PATCH 1/5] Avoid to consider lvm snapshots when scanning devices Goffredo Baroncelli
2014-12-08 2:02 ` Qu Wenruo
2014-12-08 14:58 ` Goffredo Baroncelli
2014-12-09 0:32 ` Qu Wenruo
2014-12-09 10:27 ` David Sterba
2014-12-09 18:19 ` Goffredo Baroncelli [this message]
2014-12-04 18:39 ` [PATCH 2/5] 'btrfs device scan' skips lvm snapshots Goffredo Baroncelli
2014-12-04 18:39 ` [PATCH 3/5] Update 'btrfs device scan' man page Goffredo Baroncelli
2014-12-04 18:39 ` [PATCH 4/5] Add reference to BTRFS_SKIP_LVM_SNAPSHOT environment variable Goffredo Baroncelli
2014-12-04 18:39 ` [PATCH 5/5] Abort in case of device uuid conflict Goffredo Baroncelli
2014-12-05 7:26 ` [PATCH V2][BTRFS-PROGS] Don't use LVM snapshot device Duncan
2014-12-05 18:39 ` Goffredo Baroncelli
2014-12-08 15:30 ` Phillip Susi
2014-12-08 17:36 ` Goffredo Baroncelli
2014-12-08 18:17 ` Phillip Susi
2014-12-08 19:22 ` Robert White
2014-12-10 7:52 ` Anand Jain
2014-12-10 18:40 ` Goffredo Baroncelli
-- strict thread matches above, loose matches on Subject: below --
2014-12-04 18:24 [PATCH][BTRFS-PROGS] Skip " Goffredo Baroncelli
2014-12-04 18:24 ` [PATCH 1/5] Avoid to consider lvm snapshots when scanning devices Goffredo Baroncelli
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=54873D14.8000208@inwind.it \
--to=kreijack@inwind.it \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
/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.