Re: bcache, udev rules and calling blkid
On Wed, Oct 02, 2013 at 04:01:58PM +0200, Rolf Fokkens wrote: > 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. I can concur, udev rules need some cleanup or high-level reorganization. I've hit the exact some problem when I submitted btrfs rules to dracut. They were run too early, too. Harald had to move 20-btrfs into 80-btrfs when he integrated btrfs support. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bcache, udev rules and calling blkid
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 : >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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bcache, udev rules and calling blkid
Le Lun 30 septembre 2013 09:00, Rolf Fokkens a écrit : > 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). See also https://bugzilla.redhat.com/show_bug.cgi?id=1011704 Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bcache, udev rules and calling blkid
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
