For bcache the issue seems to be resolved by renaming the 61-bcache.rules
file to 65-bcache.rules file because it's processed after 64-md-raid.rules
which calls blkid. Renaming the file however impacts dracut:
So in the end the issue is solved for bcache-tools. Relying on other rules
works for bcache-tools, but I have no idea in general. For me the
structure of the rules is not entirely clear.
Op 30-09-13 09:00 schreef Rolf Fokkens <rolf(a)rolffokkens.nl>:
On bugzilla there was a brief discussion on how to reduce the number of
blkid calls during udev rules processing:
The general idea was to rely on earlier calls to blkid instead of having
later rules calling blkid themselves. Specifically for bcache this meant
relying on 13-dm-disk.rules and 60-persistent-storage-rules, which all
worked fine until...
...until I tested stacking bcache on top of raid (md). In that situation
61-bcache.rules was out of luck, because there was no prior call to
blkid so bcache was not detected. The straight forward solution appears
to be te call blkid from 61-bcache.rules, this works any way. An
alternative solution might be to move 61-bcache.rules to 65-bcache.rules
so it is run after 64-md-raid.rules, that might work.
In general I'm a little uncomfortable with this: relying that other
rules to call blkid may work most of the time, but not always. If rules
should rely on prior calls to blkid, wouldn't it be better to call blkid
as rule 00-blk.rules or so? In that case no other rule would ever have
to call blkid ever. And yes, it may happen that blkid is sometimes
called without the output actually being used.
Any advice is appreciated,