From: Roger Leigh <rleigh@codelibre.net>
To: George Mitchell <george@chinilu.com>
Cc: util-linux@vger.kernel.org
Subject: Re: umount and findmnt commands not working with btrfs labels ...
Date: Thu, 9 May 2013 20:54:14 +0100 [thread overview]
Message-ID: <20130509195414.GU21041@codelibre.net> (raw)
In-Reply-To: <518BC86D.2050702@chinilu.com>
On Thu, May 09, 2013 at 09:01:49AM -0700, George Mitchell wrote:
> Karel, Your answer left me really frustrated, but after rethinking
> the whole thing, I am left wondering if this whole issue, including
> the broader issue of what should appear on the mount table in the
> first place, would be better addressed by the btrfs group simply
> abstracting the mount point like software raid has always done and
> handling all the details internally within btrfs. I already have
> seen applications that didn't understand btrfs partitions were in
> use and bad things could result from that. It would be nice if
> btrfs would just lock all of these partitions out and represent them
> collectively to the broader system as /dev/mntX or whatever. That
> would surely greatly simplify things for everybody. I am going
> broach that idea on the btrfs list.
If you do bring this up on the list, a related problem that breaks
a number of tools, and also boot-time fsck on Debian systems, is
that the device reported by stat(2) st_rdev is fictional and not
present in /dev. This is probably because every subvolume has a
different device ID. But it's not exposed to userspace.
If you want to get the device node to fsck from a read-only
mount, then you're stuck. And it also breaks other tools which
expect the device number to actually have real meaning. Btrfs is
AFAICT unique in this respect, and it's quite broken to behave in
this way.
If the filesystem could expose real devices to userspace, that
would IMO be a big improvement. Even if it's just a virtual
"proxy" for the filesystem.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
next prev parent reply other threads:[~2013-05-09 20:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 22:28 umount and findmnt commands not working with btrfs labels George Mitchell
2013-05-07 9:48 ` Karel Zak
2013-05-07 14:10 ` George Mitchell
2013-05-07 14:48 ` George Mitchell
2013-05-09 9:42 ` Karel Zak
2013-05-09 14:06 ` George Mitchell
2013-05-09 18:53 ` Karel Zak
2013-05-09 16:01 ` George Mitchell
2013-05-09 16:59 ` Helmut Hullen
2013-05-09 19:07 ` Karel Zak
2013-05-09 19:54 ` Roger Leigh [this message]
2013-05-10 0:15 ` George Mitchell
2013-05-10 8:28 ` Karel Zak
2013-05-07 15:10 ` George Mitchell
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=20130509195414.GU21041@codelibre.net \
--to=rleigh@codelibre.net \
--cc=george@chinilu.com \
--cc=util-linux@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox