Bug 1016131 - udev doesn't update ID_FS_TYPE of MD RAID members
udev doesn't update ID_FS_TYPE of MD RAID members
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mdadm (Show other bugs)
x86_64 Unspecified
unspecified Severity medium
: rc
: 7.3
Assigned To: Jes Sorensen
Storage QE
Depends On: 947815
  Show dependency treegraph
Reported: 2013-10-07 10:58 EDT by Jan Safranek
Modified: 2016-01-29 06:26 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 947815
Last Closed: 2016-01-22 14:55:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Safranek 2013-10-07 10:58:23 EDT
Reproducible on recent RHEL7.

+++ This bug was initially created as a clone of Bug #947815 +++

(discussed with Kay and Harald on IRC, Harald can reproduce it)

After mdadm -C ..., udev sometimes doesn't show 'ID_FS_TYPE = linux_raid_member' for a member device of the new RAID.

Version-Release number of selected component (if applicable):

How reproducible:
~ 10%

Steps to Reproduce:
1. run this loop:

for i in $(seq 100); do
    echo ---------------;
    mdadm -S /dev/md0;
    wipefs -a /dev/sdb1;
    wipefs -a /dev/sdb2;
    udevadm settle;
    udevadm info /dev/sdb1 | grep ID_FS_TYPE;
    mdadm -C --force -l 0 -n 2 /dev/md0 /dev/sdb1 /dev/sdb2;
    udevadm settle;
    udevadm info /dev/sdb1 | grep ID_FS_TYPE;
done | tee log

2. grep ID_FS_TYPE log | wc -l
Actual results:
less than 100 'ID_FS_TYPE' strings found in the log

Expected results:
exactly 100 'ID_FS_TYPE' strings found in the log

Additional info:
It is reproducible only with two devices on one disk, i.e. sdb1 and sdb2. With two different disks, e.g. sda1 and sdb1, it works well.

Also, when 'udevadm info /dev/sdb1' doesn't show ID_FS_TYPE, it is still *not* updated after ~1 minute or 'udevadm settle'. Only 'udevadm trigger' helps.
(This indicates that something did not generate some event, but I really don't know udev or kernel internals).

--- Additional comment from Harald Hoyer on 2013-04-08 16:17:10 EDT ---

With the patched mdadm, I am not able to hit the bug.

--- Additional comment from Jes Sorensen on 2013-04-11 09:35:38 EDT ---

Slightly modified patch posted upstream - lets see what the maintainer says
to it.
Comment 1 Jan Safranek 2013-10-07 10:59:24 EDT
see the Fedora bug for attachments
Comment 3 Jes Sorensen 2013-10-07 11:17:03 EDT
There was a discussion upstream, see

Message-ID: <20130429105720.593fe99b@notabene.brown>

The conclusion was pretty much NO
Comment 9 Jes Sorensen 2016-01-22 14:48:21 EST
Per comment #3, upstream didn't want to take this path - this is not going
to change.
Comment 10 RHEL Product and Program Management 2016-01-22 14:55:54 EST
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 11 Harald Hoyer 2016-01-29 06:26:01 EST
hmm.. I don't see rejection from upstream, only questions and me ranting
Comment 12 Harald Hoyer 2016-01-29 06:26:55 EST
Are you sure you want customers in RHEL-7 in this state?

Note You need to log in before you can comment on or make changes to this bug.