On Tue, 2017-02-21 at 12:32 -0700, Chris Murphy wrote: > On Tue, Feb 21, 2017 at 6:34 AM, Vratislav Podzimek <vpodzime@xxxxxxxxxx> wrote: > > > > On Wed, 2017-02-01 at 12:25 -0700, Chris Murphy wrote: > > > > > > Actually, I've got a concern about this feature. > > > > > > I'm not sure what gnome-shell depends on for monitoring mdadm arrays, > > > but I know it will put up a notification if an mdadm member becomes > > > faulty; because I've seen this notification. Maybe it's getting this > > > information from udisksd? In any case, I'm wondering whether the user > > > will still be notified of device failures in gnome-shell with this > > > change? > > I'm not seeing any code taking care of MD RAID device monitoring in > > udisks2. So it has to be somewhere else. Any ideas where to look? gvfs > > maybe? > > I'm not sure. With Fedora 25 this notification functionality is not > happening. I'm not sure what or when the regression happens, or even > if it's flawed testing. I did this in a virt-manager VM, and removing > the virtual block device, booting I get no notification. If I boot > with both devices and inside the VM I do: > > # echo 1 > /sys/block/sdb/device/delete > > I see complaints in kernel messages indicating the array is now > degraded, and udisks does pick up this fact: > > [ 80.911812] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md127/md/dev-sdb2/block symlink > [ 80.912156] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md127/md/dev-sdb2/block symlink > [ 80.912284] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md126/md/dev-sdb1/block symlink > [ 80.912414] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md126/md/dev-sdb1/block symlink Yeah, but that's not really figuring out that RAID is degraded. These are just error messages generated by udisksd still thinking the RAID is okay. So no signal emitted by udisksd here. > > But still no notification in GNOME Shell. I don't know if there's > something GNOME Shell is expecting to get additionally from udisksd, > if so it might actually be a storaged regression. In that case the > solution might need to be abstracted from GNOME Shell in storaged > anyway, because why reinvent this particular wheel in the DE? We have > degradedness notifications needed for mdadm, LVM, and Btrfs (and even > ZFS if we're asking for unicorns). Yeah, this needs some unified, generic solution. My suggestion was to use journal for this with some special key-value pair indicating that the message is actually a storage failure. That should be easy to do now that we have structured logging. And it could benefit from all the existing mechanisms developed for logging (outside of VM, log gathering,...). > > I guess I need to try this with Fedora 24 and see if it might be a > storaged regression. That's very unlikely. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
