bcache-tools package for Fedora

bcache-tools package for Fedora

[Rolf Fokkens]

Hi!

To allow Fedora users to benefit from bcache I'm currently packaging 
bcache-tools for Fedora.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=999690

Any suggestions or other feedback is welcome. Whenever I run into 
something relevant, I'll share it with the mail list.

Rolf Fokkens

Re: [RFC] bcache-status

[Rolf Fokkens]

Hi,

I took the liberty of adding bcache-status to the bcache-tools package 
I'm building:

https://bugzilla.redhat.com/show_bug.cgi?id=999690#c12

I have a few questions/remarks:
- Is the python3 dependency really needed? I changed it to ordinary 
python(2) and it runs fine I think.
- Is https://gist.github.com/damoxc/6267899 the proper source?
- When the bcache kernel module is not loaded, the feedback looks buggy:
[root@home07 ~]# bcache-status
Traceback (most recent call last):
   File "/sbin/bcache-status", line 348, in <module>
     main()
   File "/sbin/bcache-status", line 333, in main
     for cache in os.listdir(SYSFS_BCACHE_PATH):
OSError: [Errno 2] No such file or directory: '/sys/fs/bcache/'
[root@home07 ~]#

Rolf

On 08/25/2013 09:07 PM, Rolf Fokkens wrote:
> To allow Fedora users to benefit from bcache I'm currently packaging 
> bcache-tools for Fedora.
>
> See also: https://bugzilla.redhat.com/show_bug.cgi?id=999690

Re: [RFC] bcache-status

[Darrick J. Wong]

On Sun, Aug 25, 2013 at 10:39:46PM +0200, Rolf Fokkens wrote:
> Hi,
> 
> I took the liberty of adding bcache-status to the bcache-tools
> package I'm building:

Yay! :)

> https://bugzilla.redhat.com/show_bug.cgi?id=999690#c12
> 
> I have a few questions/remarks:
> - Is the python3 dependency really needed? I changed it to ordinary
> python(2) and it runs fine I think.

Not required; I'm merely writing new scripts in python3.  (At least when I can
find py3 libraries...)  I didn't write anything py3-specific, as far as I know.

> - Is https://gist.github.com/damoxc/6267899 the proper source?

I was hoping someone will (eventually) commit the status tool to
bcache-tools.git.

For now, there's: https://gist.github.com/djwong/6343451 in which I've merged
all the changes made by the two people who (thank you both!) provided
modifications.

> - When the bcache kernel module is not loaded, the feedback looks buggy:
> [root@home07 ~]# bcache-status
> Traceback (most recent call last):
>   File "/sbin/bcache-status", line 348, in <module>
>     main()
>   File "/sbin/bcache-status", line 333, in main
>     for cache in os.listdir(SYSFS_BCACHE_PATH):
> OSError: [Errno 2] No such file or directory: '/sys/fs/bcache/'
> [root@home07 ~]#

Yeah, I fixed that before posting the gist. :)

--D
> 
> Rolf
> 
> On 08/25/2013 09:07 PM, Rolf Fokkens wrote:
> >To allow Fedora users to benefit from bcache I'm currently
> >packaging bcache-tools for Fedora.
> >
> >See also: https://bugzilla.redhat.com/show_bug.cgi?id=999690
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] bcache-status

[Rolf Fokkens]

On 08/26/2013 06:30 PM, Darrick J. Wong wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=999690#c12
>
> I have a few questions/remarks:
> - Is the python3 dependency really needed? I changed it to ordinary
> python(2) and it runs fine I think.
> Not required; I'm merely writing new scripts in python3.  (At least when I can
> find py3 libraries...)  I didn't write anything py3-specific, as far as I know.
Would you consider putting python in the header instead of python3? 
Having python3 in the heading adds the requirement to install python3, 
and I think python2 is (still) more standard. For Fedora 20 I think it 
is anyway, which means I have to patch it everytime I want to package it.
> For now, there's: https://gist.github.com/djwong/6343451 in which I've merged
> all the changes made by the two people who (thank you both!) provided
> modifications.
>
> Yeah, I fixed that before posting the gist. :) --D 
Thanks, I'll update the package!

Re: [RFC] bcache-status

[Darrick J. Wong]

On Mon, Aug 26, 2013 at 10:36:11PM +0200, Rolf Fokkens wrote:
> On 08/26/2013 06:30 PM, Darrick J. Wong wrote:
> >https://bugzilla.redhat.com/show_bug.cgi?id=999690#c12
> >
> >I have a few questions/remarks:
> >- Is the python3 dependency really needed? I changed it to ordinary
> >python(2) and it runs fine I think.
> >Not required; I'm merely writing new scripts in python3.  (At least when I can
> >find py3 libraries...)  I didn't write anything py3-specific, as far as I know.
> Would you consider putting python in the header instead of python3?
> Having python3 in the heading adds the requirement to install
> python3, and I think python2 is (still) more standard. For Fedora 20
> I think it is anyway, which means I have to patch it everytime I
> want to package it.

Sure.  Go ahead and take the '3' out of hashbang.  (Gist updated.)

--D

> >For now, there's: https://gist.github.com/djwong/6343451 in which I've merged
> >all the changes made by the two people who (thank you both!) provided
> >modifications.
> >
> >Yeah, I fixed that before posting the gist. :) --D
> Thanks, I'll update the package!
> 

Re: [RFC] bcache-status

[Rolf Fokkens]

Hi,

bcache-status renders some weird output:

- "Total Cache Used" and "Total Cache Unused" don't always add up to 
"Total Cache Size"
- "Dirty Data" is -6 MB?

Seems like bugs to me. Details below.

Rolf

[root@localhost bcache]# bcache-status -s
--- bcache ---
UUID c318c0b2-0b69-4f66-a729-23b82a9d0e91
Block Size                  0.00KiB
Bucket Size                 512.00KiB
Congested?                  False
Read Congestion             2.0ms
Write Congestion            20.0ms
Total Cache Size            1.00GiB
Total Cache Used            20.00MiB    (1%)
Total Cache Unused          1.00GiB    (99%)
Dirty Data                  0B    (0%)
Evictable Cache             1.00GiB    (100%)
Replacement Policy          [lru] fifo random
Cache Mode                  [writethrough] writeback writearound none
Total Hits                  122    (100%)
Total Misses                0
Total Bypass Hits           0
Total Bypass Misses         0
Total Bypassed              0B
--- Backing Device ---
   Device File               /dev/sda3 (8:3)
   bcache Device File        /dev/bcache1 (252:1)
   Size                      7.00GiB
   Cache Mode                [writethrough] writeback writearound none
   Readahead                 0
   Sequential Cutoff         4.00MiB
   Merge sequential?         True
   State                     clean
   Writeback?                True
   Dirty Data                0B
   Total Hits                122    (100%)
   Total Misses              0
   Total Bypass Hits         0
   Total Bypass Misses       0
   Total Bypassed            0B
--- Cache Device ---
   Device File               /dev/sdb1 (8:17)
   Size                      1.00GiB
   Block Size                0.00KiB
   Bucket Size               512.00KiB
   Replacement Policy        [lru] fifo random
   Discard?                  False
   I/O Errors                0
   Metadata Written          1.00KiB
   Data Written              0B
   Buckets                   4094
   Cache Used                20.00MiB    (1%)
   Cache Unused              1.00GiB    (99%)
--- bcache ---
UUID d07cd9a1-6211-4bba-bc37-a8ba8858ef4d
Block Size                  0.00KiB
Bucket Size                 512.00KiB
Congested?                  False
Read Congestion             2.0ms
Write Congestion            20.0ms
Total Cache Size            1.00GiB
Total Cache Used            204.00MiB    (10%)
Total Cache Unused          1.00GiB    (90%)
Dirty Data                  0B    (0%)
Evictable Cache             1.00GiB    (100%)
Replacement Policy          [lru] fifo random
Cache Mode                  writethrough [writeback] writearound none
Total Hits                  1365    (81%)
Total Misses                318
Total Bypass Hits           3191    (100%)
Total Bypass Misses         0
Total Bypassed              46.00MiB
--- Backing Device ---
   Device File               /dev/sdc1 (8:33)
   bcache Device File        /dev/bcache0 (252:0)
   Size                      19.00GiB
   Cache Mode                writethrough [writeback] writearound none
   Readahead                 0
   Sequential Cutoff         0B
   Merge sequential?         True
   State                     dirty
   Writeback?                True
   Dirty Data                -6.00MiB
   Total Hits                1365    (81%)
   Total Misses              318
   Total Bypass Hits         3191    (100%)
   Total Bypass Misses       0
   Total Bypassed            46.00MiB
--- Cache Device ---
   Device File               /dev/sdd1 (8:49)
   Size                      1.00GiB
   Block Size                0.00KiB
   Bucket Size               512.00KiB
   Replacement Policy        [lru] fifo random
   Discard?                  False
   I/O Errors                0
   Metadata Written          281.00KiB
   Data Written              18.00MiB
   Buckets                   4094
   Cache Used                204.00MiB    (10%)
   Cache Unused              1.00GiB    (90%)
[root@localhost bcache]#

Re: [RFC] bcache-status

[Darrick J. Wong]

On Tue, Sep 03, 2013 at 10:46:37PM +0200, Rolf Fokkens wrote:
> Hi,
> 
> bcache-status renders some weird output:
> 
> - "Total Cache Used" and "Total Cache Unused" don't always add up to
> "Total Cache Size"

Yeah... I calculate total cache size, then cache-used = cache-size * whatever
percentage bcache reports.  It won't add up exactly due to rounding errors.
0.999 -> 1.00.  That's rather a lot, really.

> - "Dirty Data" is -6 MB?

I think this was fixed in 3.11.

--D
> 
> Seems like bugs to me. Details below.
> 
> Rolf
> 
> [root@localhost bcache]# bcache-status -s
> --- bcache ---
> UUID c318c0b2-0b69-4f66-a729-23b82a9d0e91
> Block Size                  0.00KiB
> Bucket Size                 512.00KiB
> Congested?                  False
> Read Congestion             2.0ms
> Write Congestion            20.0ms
> Total Cache Size            1.00GiB
> Total Cache Used            20.00MiB    (1%)
> Total Cache Unused          1.00GiB    (99%)
> Dirty Data                  0B    (0%)
> Evictable Cache             1.00GiB    (100%)
> Replacement Policy          [lru] fifo random
> Cache Mode                  [writethrough] writeback writearound none
> Total Hits                  122    (100%)
> Total Misses                0
> Total Bypass Hits           0
> Total Bypass Misses         0
> Total Bypassed              0B
> --- Backing Device ---
>   Device File               /dev/sda3 (8:3)
>   bcache Device File        /dev/bcache1 (252:1)
>   Size                      7.00GiB
>   Cache Mode                [writethrough] writeback writearound none
>   Readahead                 0
>   Sequential Cutoff         4.00MiB
>   Merge sequential?         True
>   State                     clean
>   Writeback?                True
>   Dirty Data                0B
>   Total Hits                122    (100%)
>   Total Misses              0
>   Total Bypass Hits         0
>   Total Bypass Misses       0
>   Total Bypassed            0B
> --- Cache Device ---
>   Device File               /dev/sdb1 (8:17)
>   Size                      1.00GiB
>   Block Size                0.00KiB
>   Bucket Size               512.00KiB
>   Replacement Policy        [lru] fifo random
>   Discard?                  False
>   I/O Errors                0
>   Metadata Written          1.00KiB
>   Data Written              0B
>   Buckets                   4094
>   Cache Used                20.00MiB    (1%)
>   Cache Unused              1.00GiB    (99%)
> --- bcache ---
> UUID d07cd9a1-6211-4bba-bc37-a8ba8858ef4d
> Block Size                  0.00KiB
> Bucket Size                 512.00KiB
> Congested?                  False
> Read Congestion             2.0ms
> Write Congestion            20.0ms
> Total Cache Size            1.00GiB
> Total Cache Used            204.00MiB    (10%)
> Total Cache Unused          1.00GiB    (90%)
> Dirty Data                  0B    (0%)
> Evictable Cache             1.00GiB    (100%)
> Replacement Policy          [lru] fifo random
> Cache Mode                  writethrough [writeback] writearound none
> Total Hits                  1365    (81%)
> Total Misses                318
> Total Bypass Hits           3191    (100%)
> Total Bypass Misses         0
> Total Bypassed              46.00MiB
> --- Backing Device ---
>   Device File               /dev/sdc1 (8:33)
>   bcache Device File        /dev/bcache0 (252:0)
>   Size                      19.00GiB
>   Cache Mode                writethrough [writeback] writearound none
>   Readahead                 0
>   Sequential Cutoff         0B
>   Merge sequential?         True
>   State                     dirty
>   Writeback?                True
>   Dirty Data                -6.00MiB
>   Total Hits                1365    (81%)
>   Total Misses              318
>   Total Bypass Hits         3191    (100%)
>   Total Bypass Misses       0
>   Total Bypassed            46.00MiB
> --- Cache Device ---
>   Device File               /dev/sdd1 (8:49)
>   Size                      1.00GiB
>   Block Size                0.00KiB
>   Bucket Size               512.00KiB
>   Replacement Policy        [lru] fifo random
>   Discard?                  False
>   I/O Errors                0
>   Metadata Written          281.00KiB
>   Data Written              18.00MiB
>   Buckets                   4094
>   Cache Used                204.00MiB    (10%)
>   Cache Unused              1.00GiB    (90%)
> [root@localhost bcache]#
> 

Re: [RFC] bcache-status

[Rolf Fokkens]

I'm not sure if I understand.

On 09/04/2013 10:26 PM, Darrick J. Wong wrote:
> Yeah... I calculate total cache size, then cache-used = cache-size * whatever
> percentage bcache reports.  It won't add up exactly due to rounding errors.
> 0.999 -> 1.00.  That's rather a lot, really.
Is the following (snippet of the output I sent) the result of rounding 
errors?

Total Cache Size            1.00GiB
Total Cache Used            204.00MiB    (10%)
Total Cache Unused          1.00GiB    (90%)

I mean: the percentages are 10% and 90%..

>> - "Dirty Data" is -6 MB?
> I think this was fixed in 3.11.
OK, so that is a kernel issue.

Re: [RFC] bcache-status

[Stefan Priebe - Profihost AG]

Am 04.09.2013 22:52, schrieb Rolf Fokkens:
> I'm not sure if I understand.
> 
> On 09/04/2013 10:26 PM, Darrick J. Wong wrote:
>> Yeah... I calculate total cache size, then cache-used = cache-size *
>> whatever
>> percentage bcache reports.  It won't add up exactly due to rounding
>> errors.
>> 0.999 -> 1.00.  That's rather a lot, really.
> Is the following (snippet of the output I sent) the result of rounding
> errors?
> 
> Total Cache Size            1.00GiB
> Total Cache Used            204.00MiB    (10%)
> Total Cache Unused          1.00GiB    (90%)
> 
> I mean: the percentages are 10% and 90%..
> 
>>> - "Dirty Data" is -6 MB?
>> I think this was fixed in 3.11.
> OK, so that is a kernel issue.

Any chance to get this fixed in 3.10 stable kernel too?

Stefan

Re: [RFC] bcache-status

[Darrick J. Wong]

On Wed, Sep 04, 2013 at 10:52:53PM +0200, Rolf Fokkens wrote:
> I'm not sure if I understand.
> 
> On 09/04/2013 10:26 PM, Darrick J. Wong wrote:
> >Yeah... I calculate total cache size, then cache-used = cache-size * whatever
> >percentage bcache reports.  It won't add up exactly due to rounding errors.
> >0.999 -> 1.00.  That's rather a lot, really.
> Is the following (snippet of the output I sent) the result of
> rounding errors?
> 
> Total Cache Size            1.00GiB
> Total Cache Used            204.00MiB    (10%)
> Total Cache Unused          1.00GiB    (90%)
> 
> I mean: the percentages are 10% and 90%..

Oops, this was a Py3 v. Py2 issue -- Python3 saw the '%.2f' in the function
that pretty-printed cache sizes and would fp-divide the two integers, whereas
Pyhon2 saw that we were trying to divide two integers and used integer
division. Fixed in the Gist.

Kent: Any chance you'd like to pick up bcache-status into bcache-tools.git?

(Or really, anyone who has commit access to that repo.)

--D
> 
> >>- "Dirty Data" is -6 MB?
> >I think this was fixed in 3.11.
> OK, so that is a kernel issue.

Re: [RFC] bcache-status

[Rolf Fokkens]

On 08/26/2013 06:30 PM, Darrick J. Wong wrote:
>
> I was hoping someone will (eventually) commit the status tool to
> bcache-tools.git.

Because packaging for Fedora requires it, I created a man page for 
bcache-status:

http://bdsync.rolf-fokkens.nl/bcache-tools-0-0.7.20130820git/bcache-status.8

maybe this helps to get it in the bcache-tools git. Another argument: 
It's a very useful tool, users will like it!

Re: bcache-tools package for Fedora / status probe-bcache

[Rolf Fokkens]

Hi,

Packaging is progressing well, an initial package is available: 
https://admin.fedoraproject.org/updates/bcache-tools-0-0.9.20130827git.fc20

probe-bcache is part of this package, but util-linux will obsolete this 
shortly: https://bugzilla.redhat.com/show_bug.cgi?id=1001120#c13 
Actually the blkid utility in util-linux will do a more thorough job on 
identifying bcache, e.g. by also checking the csum. Having blkid 
identify bcache also simplifies the bcache udev rules.

So now I'm wondering: are there any particular reasons to keep 
probe-bcache part of the package, or will it really be obsolete?

Rolf

On 08/25/2013 09:07 PM, Rolf Fokkens wrote:
> Hi!
>
> To allow Fedora users to benefit from bcache I'm currently packaging 
> bcache-tools for Fedora.
>
> See also: https://bugzilla.redhat.com/show_bug.cgi?id=999690
>
> Any suggestions or other feedback is welcome. Whenever I run into 
> something relevant, I'll share it with the mail list.
>
> Rolf Fokkens
>

Re: bcache-tools package for Fedora / status probe-bcache

[Gabriel de Perthuis]

> Hi,
> 
> Packaging is progressing well, an initial package is available:
> https://admin.fedoraproject.org/updates/bcache-tools-0-0.9.20130827git.fc20
>
>  probe-bcache is part of this package, but util-linux will obsolete
> this shortly: https://bugzilla.redhat.com/show_bug.cgi?id=1001120#c13
> Actually the blkid utility in util-linux will do a more thorough job
> on identifying bcache, e.g. by also checking the csum. Having blkid
> identify bcache also simplifies the bcache udev rules.

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.

> 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.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1001120#c9

Re: bcache-tools package for Fedora / status probe-bcache

[Rolf Fokkens]

> 
> 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.
> 
>> 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.
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1001120#c9

Re: bcache-tools package for Fedora / status probe-bcache

[Gabriel de Perthuis]

>> 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

Re: bcache-tools package for Fedora / status probe-bcache

[Karel Zak]

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

Re: bcache-tools package for Fedora / status probe-bcache

[Gabriel de Perthuis]

lun. 09 sept. 2013 15:26:53 CEST, Karel Zak a écrit :
> 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?

It's correct insofar as current consumers expect it, and it's better
for error reporting.  The patches took care of my other objections,
so you can keep the crc check and go with what's on
https://github.com/g2p/util-linux/commits
(the csum patches I sent + Rolf's patch + a patch that depends on both).

>> 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.

The second patch does that, and the first one also prevents exposing
nested data when a csum is broken, which was a dangerous failure mode.

>  Something else (like report bad checksums to udev) is probably
>  unnecessary. Right?

It would be good to have, because silent boot failures suck.
Maybe as a tweak to udev's embedded blkid?

>>> 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. 

(Letting Rolf field this one)

Re: bcache-tools package for Fedora / status probe-bcache

[Rolf Fokkens]

Op 09-09-13 17:28 schreef Gabriel de Perthuis <g2p.code-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

>> Maybe we can backport the patch to F20 if you need it -- it's not too
>>  invasive change.
>
>(Letting Rolf field this one)

Most important for me is to have bcache identification by blkid in before
F20, so the udev rules file doesn't have to call bcache-probe. Whether or
not it uses checksums is not the most important thing, and that aspect
might even change later.

Re: bcache-tools package for Fedora / status probe-bcache

[Karel Zak]

On Mon, Sep 09, 2013 at 05:28:57PM +0200, Gabriel de Perthuis wrote:
> It's correct insofar as current consumers expect it, and it's better
> for error reporting.  The patches took care of my other objections,
> so you can keep the crc check and go with what's on
> https://github.com/g2p/util-linux/commits
> (the csum patches I sent + Rolf's patch + a patch that depends on both).

Merged with some changes

 - not added blkid_probe_is_badcsum() the info about bad csum is
   exported by SBBADCSUM=1 variable, you have to use for example:

       if (blkid_probe_has_value(pr, "SBBADCSUM"))....

 - the usage type is BLKID_USAGE_OTHER rather than "raid" (we have some
   special exceptions and tests for raids that are unnecessary for
   bcache)

I have also added the test images from Rolf to util-linux test suite.

 $ blkid -o udev -p  tests/output/blkid/images-fs/bcache-C.img 
 ID_FS_UUID=7a343627-ac87-4bf0-b76f-46067cbc9b8c
 ID_FS_UUID_ENC=7a343627-ac87-4bf0-b76f-46067cbc9b8c
 ID_FS_TYPE=bcache
 ID_FS_USAGE=other

Thanks!

    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