Re: 64-btrfs.rules and degraded boot

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-07-07 14:58, Chris Murphy wrote:
> On Thu, Jul 7, 2016 at 12:23 PM, Austin S. Hemmelgarn
> <ahferroin7@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).