>> I'm not a fan of a blkid csum check (I pointed it out on the >> bug[1]). If a superblock gets scribbled or corrupted, you want >> bcache to complain, and you don't want blkid to look for the next >> possible signature. > > Having blkid also verify the csum was requested by Karel Zak, the > maintainer of util-linux. As a packager of bcache-tools I'm in favour > of having blkid identify bcache, but I don't have a preference on > using csum to identify bcache. I can pass the message to Karel, but > it would be better if we both discuss it on the appropriate > (util-linux?) mail list. Karel, are you okay if blkid doesn't do the csum verification discussed above? Checksum failures will be reported by the kernel instead. Alternatively, do you see a way libblkid can return good magic / bad checksum results? >>> So now I'm wondering: are there any particular reasons to keep >>> probe-bcache part of the package, or will it really be obsolete? >> >> If you address the above and tweak the udev rules, why not. >> >> The upstream repo will need to keep probe-bcache for a while >> longer, because we don't have a way to require a sufficiently >> recent libblkid. > > I agree, f20 is a specific case, but in general probe-bcache will be > needed for a while. For the record, the libblkid patch is a good thing in the long run: common interface, less forks in udev. >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1001120#c9 -- 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
