On Tue, 2017-02-21 at 12:32 -0700, Chris Murphy wrote:
On Tue, Feb 21, 2017 at 6:34 AM, Vratislav Podzimek
> 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
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: Unable to resolve
[ 80.912156] localhost.localdomain udisksd: Unable to resolve
[ 80.912284] localhost.localdomain udisksd: Unable to resolve
[ 80.912414] localhost.localdomain udisksd: Unable to resolve
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
That's very unlikely.
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic