From: Goffredo Baroncelli <kreijack@inwind.it>
To: Chris Murphy <lists@colorremedies.com>,
"Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Andrei Borzenkov <arvidjaar@gmail.com>,
Kai Krakow <hurikhan77@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: 64-btrfs.rules and degraded boot
Date: Thu, 7 Jul 2016 22:13:05 +0200 [thread overview]
Message-ID: <e6209439-e4cc-c8fe-a91f-03772f3965e5@inwind.it> (raw)
In-Reply-To: <CAJCQCtS7=bR_r6+u+vSxE7rfUOOwx0G3NTff4=WUbfV3riWVSA@mail.gmail.com>
On 2016-07-07 20:58, Chris Murphy wrote:
> I get all kinds of damn strange behaviors in GNOME
> with Btrfs multiple device volumes: volume names appearing twice in
> the UI, unmounting one causes umount errors with the other.
> https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged
> http://storaged.org/
Unfortunately BTRFS is a mess from this point of view. Some btrfs subcommand query the system inspecting directly the data stored on the disks; others use the ioctl(2) syscall, which provides what the kernel think. Unfortunately, due to the cache, these two kind of source of information are out of sync.
Often, when some command output don't convince me, I do some "sync"; then repeating the command the output is better ("btrfs fi show" is one of these commands).
BR
G.Baroncelli
--
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:[~2016-07-07 20:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 18:53 64-btrfs.rules and degraded boot Chris Murphy
2016-07-05 19:27 ` Kai Krakow
2016-07-05 19:30 ` Chris Murphy
2016-07-05 20:10 ` Chris Murphy
2016-07-06 9:51 ` Andrei Borzenkov
2016-07-06 11:45 ` Austin S. Hemmelgarn
2016-07-06 11:55 ` Andrei Borzenkov
2016-07-06 12:14 ` Austin S. Hemmelgarn
2016-07-06 12:39 ` Andrei Borzenkov
2016-07-06 12:48 ` Austin S. Hemmelgarn
2016-07-07 16:52 ` Goffredo Baroncelli
2016-07-07 18:23 ` Austin S. Hemmelgarn
2016-07-07 18:58 ` Chris Murphy
2016-07-07 19:14 ` Chris Murphy
2016-07-07 19:59 ` Austin S. Hemmelgarn
2016-07-07 20:20 ` Chris Murphy
2016-07-08 12:24 ` Austin S. Hemmelgarn
2016-07-11 21:07 ` Chris Murphy
2016-07-12 15:34 ` Austin S. Hemmelgarn
2016-07-07 20:13 ` Goffredo Baroncelli [this message]
2016-07-07 19:41 ` Goffredo Baroncelli
2016-07-06 12:49 ` Tomasz Torcz
2016-07-06 17:19 ` Chris Murphy
2016-07-06 18:04 ` Austin S. Hemmelgarn
2016-07-06 18:23 ` Chris Murphy
2016-07-06 18:29 ` Andrei Borzenkov
2016-07-06 19:17 ` Austin S. Hemmelgarn
2016-07-06 20:00 ` Chris Murphy
2016-07-07 17:00 ` Goffredo Baroncelli
2016-07-06 18:24 ` Andrei Borzenkov
2016-07-06 18:57 ` Chris Murphy
2016-07-07 17:07 ` Goffredo Baroncelli
2016-07-07 16:37 ` 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=e6209439-e4cc-c8fe-a91f-03772f3965e5@inwind.it \
--to=kreijack@inwind.it \
--cc=ahferroin7@gmail.com \
--cc=arvidjaar@gmail.com \
--cc=hurikhan77@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.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 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).