Re: F26 Self Contained Change: Anaconda LVM RAID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux