On 2016-07-07 14:58, Chris Murphy wrote:
On Thu, Jul 7, 2016 at 12:23 PM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
Here's how I would picture the ideal situation:
* A device is processed by udev. It detects that it's part of a BTRFS
array, updates blkid and whatever else in userspace with this info, and then
stops without telling the kernel.
* The kernel tracks devices until the filesystem they are part of is
unmounted, or a mount of that FS fails.
* When the user goes to mount the a BTRFS filesystem, they use a mount
helper.
1. This helper queries udev/blkid/whatever to see which devices are part
of an array.
2. Once the helper determines which devices are potentially in the
requested FS, it checks the following things to ensure array integrity:
- Does each device report the same number of component devices for the
array?
- Does the reported number match the number of devices found?
- If a mount by UUID is requested, do all the labels match on each
device?
- If a mount by LABEL is requested, do all the UUID's match on each
device?
- If a mount by path is requested, do all the component devices reported
by that device have matching LABEL _and_ UUID?
- Is any of the devices found already in-use by another mount?
4. If any of the above checks fails, and the user has not specified an
option to request a mount anyway, report the error and exit with non-zero
status _before_ even talking to the kernel.
5. If only the second check fails (the check verifying the number of
devices found), and it fails because the number found is less than required
for a non-degraded mount, ignore that check if and only if the user
specified -o degraded.
6. If any of the other checks fail, ignore them if and only if the user
asks to ignore that specific check.
7. Otherwise, notify the kernel about the devices and call mount(2).
* The mount helper parses it's own set of special options similar to the
bg/fg/retry options used by mount.nfs to allow for timeouts when mounting,
as well as asynchronous mounts in the background.
* btrfs device scan becomes a no-op
* btrfs device ready uses the above logic minus step 7 to determine if a
filesystem is probably ready.
Such a situation would probably eliminate or at least reduce most of our
current issues with device discovery, and provide much better error
reporting and general flexibility.
It might be useful to see where ZFS and LVM work and fail in this
regard. And also plan for D-Bus support to get state notifications up
to something like storaged or other such user space management tools.
Early on in Fedora there were many difficulties between systemd and
LVM, so avoiding whatever that was about would be nice.
D-Bus support needs to be optional, period. Not everybody uses D-Bus (I
have dozens of systems that get by just fine without it, and know
hundreds of other people who do as well), and even people who do don't
always use every tool needed (on the one system I manage that does have
it, the only things I need it for are Avahi, ConsoleKit, udev, and
NetworkManager, and I'm getting pretty close to the point of getting rid
of NM and CK and re-implementing or forking Avahi). You have to
consider the fact that there are and always will be people who do not
install a GUI on their system and want the absolute minimum of software
installed.
Also, tangentially related, Fedora is replacing udisks2 with storaged.
Storaged already has a Btrfs plug-in so there should be better
awareness there. 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/
Personally, I don't care what Fedora is doing, or even what GNOME (or
any other DE for that matter, the only reason I use Xfce is because some
things need a GUI (many of them unnecessarily), and that happens to be
the DE I have the fewest complaints about) is doing. The only reason
that things like GNOME Disks and such exist is because they're trying to
imitate Windows and OS X, which is all well and good for a desktop, but
is absolute crap for many server and embedded environments (Microsoft
finally realized this, and Windows Server 2012 added the ability to
install without a full desktop, which actually means that they have
_more_ options than a number of Linux distributions (yes you can rip out
the desktop on many distros if you want, but that takes an insane amount
of effort most of the time, not to mention storage space)).
Storaged also qualifies as something that _needs_ to be optional,
especially because it appears to require systemd (and it falls into the
same category as D-Bus of 'unnecessary bloat on many systems'). Adding
a mandatory dependency on systemd _will_ split the community and
severely piss off quite a few people (you will likely get some rather
nasty looks from a number of senior kernel developers if you meet them
in person).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
