Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
work around failure of udev to observe btrfs device add #1606
In some rare instances it is possible for udev and lsblk to fail to reflect the current state of a pools disk members. This was initially observed while testing btrfs in partition device members in issue #1494, however I have now duplicated the same failure using whole disk members.
So far this has been observed (sporadically) only directly after adding a device to a pool, but only after a few such operations have taken place just prior to the issue related device add. The most reliable indicator was still very intermittent but essentially involved adding and then removing and re-adding the same device to a pool, often multiple times.
The fail state is identified by lsblk and udev info not having been updated directly after the following command:
The failed state is then persistent. It was found the ‘btrfs device scan’ had no effect but:
where vdd2 (a partitioned pool device member) was added but not accounted for in lsblk or udev info.
Which also succeeded in returning udev and lsblk output to what would normally be expected, ie in line with the output of btrfs fi show.
Given Rockstor reliance on udev to maintain a current view on devices the resulting failed state causes the most recently added device to not be listed or recognised as a pool member.
Examples of failed / inconsistent state between btrfs fi show and udev / lsblk.
But an lsblk output that fails to show /dev/vdd2 (devid 3 in above):
Also note that udevadm info --name /dev/vdd2 | grep FS_ had no output.
In the above case the "echo change > /sys/block/vdd/vdd2/uevent" was found to resolve the inconsistency.
Another example involved a 2 device pool having no btrfs info reflected by udev and lsblk for either of it's members:
where "lsblk -a -P -o NAME,TYPE,FSTYPE,LABEL,UUID | grep testpool"
Another example involved a single device pool where that device pool member had no btrfs related info in udev or lsblk:
and again no appropriate btrfs or label info found in lsblk's output yet we have an active mount:
In this case I was able to test the "udevadm trigger" command and then we see:
So we have our return lsblk info on btrfs.
where they had previously been absent.
Finally I was able to catch a full disk example:
And the lsblk output for the command:
ie no entry for /dev/vdf
When at the same time we see no output from "udevadm info --name /dev/vdf | grep FS_"
added a commit
Jan 9, 2017
referenced this issue
Jan 9, 2017
Thank to maxhq in the following forum thread for also confirming the same behaviour can be seen after the:
command which also adds a disk but also removes another. The same 'udevadm trigger' command succeeded in restoring the expected udev/lsblk output in that case: