From: Gabriel de Perthuis <g2p.code-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Rolf Fokkens <rolf-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>,
"linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
util-linux <util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: bcache-tools package for Fedora / status probe-bcache
Date: Thu, 05 Sep 2013 12:53:13 +0200 [thread overview]
Message-ID: <52286299.7000708@gmail.com> (raw)
In-Reply-To: <FEBD3400-93F1-4286-8BE8-45D5413C2EA2-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
>> 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 util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Gabriel de Perthuis <g2p.code@gmail.com>
To: Karel Zak <kzak@redhat.com>
Cc: Rolf Fokkens <rolf@rolffokkens.nl>,
"linux-bcache@vger.kernel.org" <linux-bcache@vger.kernel.org>,
util-linux <util-linux@vger.kernel.org>
Subject: Re: bcache-tools package for Fedora / status probe-bcache
Date: Thu, 05 Sep 2013 12:53:13 +0200 [thread overview]
Message-ID: <52286299.7000708@gmail.com> (raw)
In-Reply-To: <FEBD3400-93F1-4286-8BE8-45D5413C2EA2@rolffokkens.nl>
>> 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
next prev parent reply other threads:[~2013-09-05 10:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-25 19:07 bcache-tools package for Fedora Rolf Fokkens
[not found] ` <521A55D4.20908-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
2013-08-25 20:39 ` [RFC] bcache-status Rolf Fokkens
[not found] ` <521A6B92.60001-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
2013-08-26 16:30 ` Darrick J. Wong
[not found] ` <20130826163055.GB4780-yuuUpGxbzT9UbpRmUfBrXUB+6BGkLq7r@public.gmane.org>
2013-08-26 20:36 ` Rolf Fokkens
[not found] ` <521BBC3B.9010003-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
2013-08-29 0:46 ` Darrick J. Wong
[not found] ` <20130829004646.GA3099-yuuUpGxbzT9UbpRmUfBrXUB+6BGkLq7r@public.gmane.org>
2013-09-03 20:46 ` Rolf Fokkens
[not found] ` <52264AAD.3050401-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
2013-09-04 20:26 ` Darrick J. Wong
[not found] ` <20130904202600.GA4554-yuuUpGxbzT9UbpRmUfBrXUB+6BGkLq7r@public.gmane.org>
2013-09-04 20:52 ` Rolf Fokkens
[not found] ` <52279DA5.7050505-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
2013-09-05 6:14 ` Stefan Priebe - Profihost AG
2013-09-09 22:45 ` Darrick J. Wong
2013-08-26 23:01 ` Rolf Fokkens
2013-09-05 6:53 ` bcache-tools package for Fedora / status probe-bcache Rolf Fokkens
[not found] ` <52282A87.4000801-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
2013-09-05 10:16 ` Gabriel de Perthuis
[not found] ` <52285A03.7080802-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-05 10:36 ` Rolf Fokkens
[not found] ` <FEBD3400-93F1-4286-8BE8-45D5413C2EA2-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org>
2013-09-05 10:53 ` Gabriel de Perthuis [this message]
2013-09-05 10:53 ` Gabriel de Perthuis
[not found] ` <52286299.7000708-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-09 13:26 ` Karel Zak
2013-09-09 13:26 ` Karel Zak
[not found] ` <20130909132653.GA8061-s5vVilr7EKH/9pzu0YdTqQ@public.gmane.org>
2013-09-09 15:28 ` Gabriel de Perthuis
2013-09-09 15:28 ` Gabriel de Perthuis
[not found] ` <522DE939.5090009-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-11 11:59 ` Rolf Fokkens
2013-09-11 11:59 ` Rolf Fokkens
2013-09-11 15:51 ` Karel Zak
2013-09-11 15:51 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52286299.7000708@gmail.com \
--to=g2p.code-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rolf-6w2rdlBuEQTpMFipWq+H6g@public.gmane.org \
--cc=util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.