Hi, 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: https://bugzilla.redhat.com/show_bug.cgi?id=1014625 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. Rolf Op 30-09-13 09:00 schreef Rolf Fokkens <rolf@xxxxxxxxxxxxxx>: >Hi, > >On bugzilla there was a brief discussion on how to reduce the number of >blkid calls during udev rules processing: > >https://bugzilla.redhat.com/show_bug.cgi?id=1004693 > >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, > >Thanks, > >Rolf -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
