From: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Gabriel de Perthuis <g2p.code-Re5JQEeQqe8AvxtiuMwx3w@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: Mon, 9 Sep 2013 15:26:53 +0200 [thread overview]
Message-ID: <20130909132653.GA8061@x2.net.home> (raw)
In-Reply-To: <52286299.7000708-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Sep 05, 2013 at 12:53:13PM +0200, Gabriel de Perthuis wrote:
> >> 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?
I don't insist on csum, but I'd like to have something more robust
than check for a magic string only. It's usually better if there
is some additional thing (for example within superblock offset,
csum, etc.) -- checksums are ideal because it usually verifies
whole superblock (header).
> Checksum failures will be reported by the kernel instead.
I don't care about kernel :-) The important is what userspace (udev)
thinks about the device -- is it correct to trigger any action on
broken bcache device or the device should be ignored by userspace
rules?
> Alternatively, do you see a way libblkid can return good magic / bad checksum
> results?
If I good understand your patches then it makes wipefs(8) more
"hungry" to zap incomplete superblock. I have no problem to support
this scenario.
Something else (like report bad checksums to udev) is probably
unnecessary. Right?
> > 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.
Yes, definitely.
Maybe we can backport the patch to F20 if you need it -- it's not too
invasive change.
Karel
--
Karel Zak <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
http://karelzak.blogspot.com
--
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
next prev parent reply other threads:[~2013-09-09 13:26 UTC|newest]
Thread overview: 19+ 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
[not found] ` <52286299.7000708-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-09 13:26 ` Karel Zak [this message]
[not found] ` <20130909132653.GA8061-s5vVilr7EKH/9pzu0YdTqQ@public.gmane.org>
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 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=20130909132653.GA8061@x2.net.home \
--to=kzak-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=g2p.code-Re5JQEeQqe8AvxtiuMwx3w@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox