---
This should fix it.
Because the raid superblock is at the end of the device, bcache's
udev rules could detect a bcache device on the unassembled raid
member. A better fix would be to merge probe-bcache into
util-linux's blkid.
61-bcache.rules | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/61-bcache.rules b/61-bcache.rules
index 22c1a90..dd85e69 100644
--- a/61-bcache.rules
+++ b/61-bcache.rules
@@ -3,14 +3,19 @@
SUBSYSTEM!="block", GOTO="bcache_end"
ACTION=="remove", GOTO="bcache_end"
# Backing devices: scan, symlink, register
+IMPORT{program}="/sbin/blkid -o udev $tempnode"
+# blkid and probe-bcache can disagree, in which case don't register
+ENV{ID_FS_TYPE}=="?*", ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
+
IMPORT{program}="/sbin/probe-bcache -o udev $tempnode"
ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="bcache", \
RUN+="bcache-register $tempnode"
+LABEL="bcache_backing_end"
# Cached devices: symlink
DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
--
1.8.3.3.758.g90e98ff
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
