Re: Upgrade to Fedora 30 consistently corrupts bcache storage - is there some kind of emergency brake possible during upgrade?

[Rolf Fokkens]

Thx! I followed your suggestions!

On 5/12/19 7:59 PM, Tomasz Torcz wrote:

On Sun, May 12, 2019 at 01:09:40PM +0200, Rolf Fokkens wrote:

Hi All,

There's this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1708315

Would have been better if I discovered it during Alpha or Beta, but
unfortunately I didn't. Now we have the situation that any bcache user
upgrading to Fedora30 involuntarily currupts his storage.


   This is huge!  Accidentaly, after upgrade to F30 I experience
two or three I/O hangs with bcache, so I temporarily detached cache
device and (knock on wood) there are no problems (my rootfs is btrfs
raid10 over bcache devices).

   I suggest:
   1) getting this bug into F30 Common Bugs page, with hint that
   detaching cache device before upgrade could help.
   2) complement rhbz#1708315 with pointers to upstream report.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Upgrade to Fedora 30 consistently corrupts bcache storage - is there some kind of emergency brake possible during upgrade?

[Rolf Fokkens]

Hi All,

There's this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1708315

Would have been better if I discovered it during Alpha or Beta, but 
unfortunately I didn't. Now we have the situation that any bcache user 
upgrading to Fedora30 involuntarily currupts his storage.


I tried to limit the impact by using a %pretrans script in bcache-tools:

%pretrans
_bcache=`find /sys/block/ -maxdepth 1 -name "bcache[0-9]*" | wc -l`
[[ $_bcache -gt 0 ]] || exit 0
cat >&2 << EOF
bcache will likely corrupt Fedora 30 systems beyond repare.
https://bugzilla.redhat.com/show_bug.cgi?id=1708315
EOF
exit 1

But this only blocks upgrading/installing bcache-tools. The rest 
(including the kernel) is still upgraded so after a reboot the storage 
will get corrupted anyway. Of course adding this to the kernel package 
would do the trick, but I'm not sure if that is an option.


Any suggestions on how to save people from running into this are very 
welcome!


Cheers,

Rolf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Removal of GCC from the buildroot

[Rolf Fokkens]

This bit the bcache-tools package too, which I fixed.

On 07/13/2018 12:39 PM, Igor Gnatenko wrote:
On Fri, Jul 13, 2018, 11:19 Miro Hrončok > wrote:


On 8.7.2018 20:46, Igor Gnatenko wrote:
> As per Changes/Remove GCC from BuildRoot
>
,
I'm
> going to automatically add BuildRequires: gcc and/or BuildRequires:
> gcc-c++ to packages which fail to build with common messages
(like gcc:
> command not found, also autotools/cmake/meson are supported).
>
> I'm going to do this tomorrow.
>
> After which, I'm going to ask rel-eng to finally remove it from
> buildroot. This will happen before mass rebuild. Stay tuned.
> --

I've clicked randomly trough failures during the mass rebuild at [1].

I see quite a lot of commands not founds for gcc, cc, c++...

I think the maintainers should add them and that's fine, but it
seemed
that during this change you said you will add those. Did it happen?


Yes, I've pushed over 2k commits adding those, however regexp might 
have not catched all possible cases. Would appreciate if you would 
link such packages so that I can fix them. Or maintainers can do it 
themselves.


[1] https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html

-- 
Miro Hrončok

--
Phone: +420777974800
IRC: mhroncok

--

-Igor Gnatenko



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/INTODKJDI2NU36RBHKPYNLDOPSBRAPV6/



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3EI357BHP6LWUEJH7FM6R3KYX4RLHFZA/

When to make packeges "dnf protected"

[Rolf Fokkens]

Hi all,

As the maintainer of bcache-tools I ran into the situation that a 
collegue accidentally removed bcache-tools, resulting in a system that 
failed to boot after installing and using a new kernel. dnf logs showed 
that the package had been erased, with a bunch of other packages. It 
happened 3 weeks ago, and the colleague did not recall what he actually 
did at that time.


I'm considering to make bcache-tools protected (by including a config 
file in the package in /etc/dnf/protected.d/) to prevent accidental 
erasure of the package. Is this the proper way to prevent this situation?


Cheers,

Rolf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: bcache strategies for consistency in case of powerloss

[Rolf Fokkens]

Hi Florian,

On 10/25/2013 11:44 AM, Florian Weimer wrote:

On 10/15/2013 09:13 PM, Rolf Fokkens wrote:

On 10/14/2013 10:08 AM, Florian Weimer wrote:

Is there a write-up somewhere documenting what strategies are
implemented by bcache to keep the SSD and the hard disk contents in
sync even in the event of a sudden power loss?

This is good place to start: http://bcache.evilpiepirate.org/


It doesn't actually address this as far as I can see.  It only 
describes how the data structure integrity is maintained on the SSD 
side.  Even that doesn't seem to address torn writes (which are 
problem for cheap-to-medium-grade SSDs).  The code contains propagate 
barriers as a to-do item (see the beginning of 
drivers/md/bcache/btree.c).  I couldn't find anything that discusses 
write ordering issues which can occur in write-through mode.


I don't have the expertise myself to answer your question, so I hereby 
forward this question to Kent and Gabriel and the bcache mail list.


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-tools and bcache support in other linux packages

[Rolf Fokkens]

On 10/23/2013 04:01 AM, Paul B. Henson wrote:
I believe that quote describes what we'd like to do someday, not 
what it does now? 

You're right, it's about plans for the future.
--
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-tools and bcache support in other linux packages

[Rolf Fokkens]

On 10/22/2013 07:53 PM, Rolf Fokkens wrote:
Well, I agree, there's more to it. Like cost. One could consider to 
pair serveral HHD' each with a dedicated bcache SSD. And from that one 
could build a RAID array. This RAID array has excellent (read) 
performance because of the combined SSD performance. This storage 
system does break when one of the HDD's or SDD's breaks, which is also 
a nice feature. So if it weren't for the cost (and the number of 
availbale SATA connectors) this could be interresting. But it's all a 
matter of requirements of course.
I noticed a somewhat confusing typo, the right sentence is This storage 
system does NOT break when one of the HDD's or SDD's breaks.

--
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-tools and bcache support in other linux packages

[Rolf Fokkens]

On 10/21/2013 06:47 PM, Piergiorgio Sartor wrote:


Interesting, then logic would suggest to (b)cache
the components of the RAID.
Of, even better, to (b)cache /dev/sd[ab] (in this
case) and cover, in this way, everything.
Well, I agree, there's more to it. Like cost. One could consider to pair 
serveral HHD' each with a dedicated bcache SSD. And from that one could 
build a RAID array. This RAID array has excellent (read) performance 
because of the combined SSD performance. This storage system does break 
when one of the HDD's or SDD's breaks, which is also a nice feature. So 
if it weren't for the cost (and the number of availbale SATA connectors) 
this could be interresting. But it's all a matter of requirements of course.

It's a desktop PC, I notice that performances
mainly depend on the storage subystem, the rest
(CPU, memory, GPU) is fine for me.


In my desktop PC I'm running singls SSD bcache on a RAID5 array. The 
performance is fine, and when the SSD breaks, well, I hope the FS on the 
HDD can be recovered. And if not? Well, it's only a desktop PC.


And when using multiple SSD's for reduncancy, the following article 
covers some interresting features in bcache:


http://www.linux.com/news/featured-blogs/200-libby-clark/728209-about-the-linux-kernel-bcache

Quote Multiple SSDs will allow us to mirror dirty data and metadata, 
but not clean data - you get redundancy without wasting SSD space 
duplicating clean cached data.

--
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-tools and bcache support in other linux packages

[Rolf Fokkens]

Op 10/20/13 8:59 PM schreef Piergiorgio Sartor
piergiorgio.sar...@nexgo.de:

Does the tools converts the complete RAID-10, including
the LVM volumes to bcache?

I will look into the blocks tool for F21, but for now I leave answering
the question to Gabriel.

Some times ago I asked, in my setup, what would be the
right approach to bcache, between caching the RAID
or caching each LVM volume and the answer was that the
usual way is to cache the RAID.

Any changes on this statement?

I can imagine that one may wish to (b)cache one specific LV and not the
other(s) in the same VG in which case bcache is to be used on top of the
specific LV. I think in general however it's best to use LVM on top of
bcache because it's closer to the (slow) storage you want to accelerate.
So I guess it depends on your requirements.

I'm not sure if there are specific technical arguments in favour of one or
the other. But I can say I've seen both work during testing.

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-tools and bcache support in other linux packages

[Rolf Fokkens]

Hi Reartes,

On 10/18/2013 05:57 PM, Reartes Guillermo wrote:

I tested F20 on a physical host with a vertex3 ssd.
But it was not a requested test case, i re-used a md raid0 with a 6gb
partition of the ssd.

The file-system was setup as a storage pool for virt-manager.

I did not experience any issues, i installed 2 F20 guest at the same time.
I even rebooted many times and it survived several kernel updates.
I did not test a power-loss scenario. I has been working ok since a
couple of days.

I also did the non lvm tests on guest, without any issue.

Thanks for your feedback, glad to hear it works well for you.

The only thing that i can recall as strange is the fact that bcache
seems to not to use discard/trim for some reason.

discard/trim can be enabled, see:
http://evilpiepirate.org/git/linux-bcache.git/tree/Documentation/bcache.txt?h=bcache-dev#n126

There's also an explanation in the document why it isn't enabled by default:
|Defaults to off, since SATA TRIM is an unqueued command (and thus slow).

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-tools and bcache support in other linux packages

[Rolf Fokkens]

Hi all,

We've been waiting to see if other people who couldn't make on Sunday
would also do some testing. That hasn't happened, so a few words on my
impressions on the test day are appropriate indeed.

First of all not many people really did some testing. We didn't expect
many people to participate, but the 3 people who did (many thanks to
them!) were the bare minimum we anticipated. This was probably caused by
the following:
- SSD caching may need more explanation, not many people understand what
it is and what the benefits are
- Because it's hard to change an existing partition to a 'bcached'
partition, it's not really tempting to test (there's a blocks utility
under development that may help, currently backup-restore is the only way).
- Not many people have the required resources available to do testing.
Even when testing in a VM not many people have the required 10GB available
(The requirements could be lowered top about 6GB, so that might help)
- Installing F20 as requested in the prerequisites was harder to the
testers than we anticipated. Specifically planning a specific partition
layout in Anaconda requires a lot of attention (I could upload a VM image
somewhere to facilitate that).

About the testing itself:
- the alignment of the tools (bcache-tools, kernel, util-linux and dracut)
is really good now, people were able to do the testcases (1.A and 1.B)
without a hitch.
- nobody tested the LVM integration (testcases 2.A and 2.B), so no test
results on that part.
- Unfortunately kernel 3.11.4 (which was the latest version on Sunday)
exhibited a bug during stress testing
(https://bugzilla.redhat.com/show_bug.cgi?id=1018615), but that bug is
supposed to be fixed in kernel 3.11.5 which was released later this week.

So I think SSD Caching (using bcache) is in a good shape, but I would like
to encourage people to do some more testing. Of course other feedback is
also appreciated.

Thanks,

Rolf

Op 10/18/13 11:22 AM schreef Piergiorgio Sartor
piergiorgio.sar...@nexgo.de:

On Thu, Sep 26, 2013 at 11:56:25AM +0200, Rolf Fokkens wrote:
[...]
 The SSD Cache Fedora test day
 =
 On 13th of October there's an SSD Cache Fedora test day: see the
 Wiki page
 https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache. This
 page is work in progress, any feedback is welcome. People interested
 in testing are invited to participate on 13th of October.
 
 When there's anything new toreport, I'll keep you posted.

Hi Rolf,

could you spend few words about the results
of the SSD Cache Fedora test day?

Anything interesting or surprising happened?
Any disappointment?

Thanks,

bye,

-- 

piergiorgio


-- 
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: Sunday 13th of October: SSD cache test day

[Rolf Fokkens]

On 10/14/2013 10:08 AM, Florian Weimer wrote:
Is there a write-up somewhere documenting what strategies are 
implemented by bcache to keep the SSD and the hard disk contents in 
sync even in the event of a sudden power loss?

This is good place to start: http://bcache.evilpiepirate.org/
--
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: Sunday 13th of October: SSD cache test day

[Rolf Fokkens]

On 10/12/2013 10:58 PM, Reartes Guillermo wrote:

Maybe that can be enhanced to say cset.uuid instead of just uuid /
set uuid? (for which i confused it with dev.uuid shown by blkid,
since i never used bcache before).
cset.uuid can be obtained from the output of bcache-show-super.

Cheers.

Thanks, I updated the text!

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

Sunday 13th of October: SSD cache test day

[Rolf Fokkens]

Hi All,

The Fedora SSD Cache is this sunday October 13th 2013. This Fedora Test 
Day will focus on bcache based SSD Caching in Fedora 20.


https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache

If you're interested in trying out the new bcache SSD caching 
functionality step by step instructions are available for:


- bcache on physical hardware
- bcache in a virtual machine
- non-root FS on bcache (with or without LVM)
- root FS on bcache (wtih or without LVM)

The objective of this Test day is to demonstrate a working Fedora 20 
system using bcache. Te be more specific:


 * The system boots OK; after booting bcache is operating as expected
 * The system updates (yum update) OK. After updating specifically
   the kernel the system boots OK.
 * The system is bootable when the caching device is disabled.

Although testing on real hardware is closest to the real thing, 
testing in a VM may also provide good insights on the proper working of 
bcache (except for performance).


If you can't make the date of the test day, adding test case results to the 
wiki anytime next week is fine as well. Though if you do plan on showing up to 
the test day,
please add your name to the participant list on the wiki, and when the day 
arrives, pop into #fedora-test-day on freenode and give us a shout! If you 
can't make the date
of the test day, adding test case results to the wiki anytime next week is fine 
as well. Though if you do plan on showing up to the test day, add your name to 
the
participant list on the wiki, and when the day arrives, pop into 
#fedora-test-day on freenode and give us a shout!

The Wiki page is still under development, so expect some improvements 
before sunday.


Thanks,

Igor Gnatenko
Rolf Fokkens

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

[Rolf Fokkens]

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 r...@rolffokkens.nl:

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

bcache, udev rules and calling blkid

[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-tools and bcache support in other linux packages

[Rolf Fokkens]

Hi

It was brought to my attention that there's a confusing typo in the
message below regarding the planning of bcache support for anaconda. The
claim that it is planned for F20 is not true, it is planned for F21:

https://fedorahosted.org/fesco/ticket/1145

Sorry for any confusion,

Rolf

Op 26-09-13 11:56 schreef Rolf Fokkens r...@rolffokkens.nl:

Hi,

Like I did on the 14th on the linux-bcache list I'd like to send an
update on the progress of bcache related packages. While focussing on
Fedora packaging of bcache-tools, I had some good collaboration with
other packagers resulting in improved bcache support in other packages
as well. Other Linux distro's may benefit from these updated packages too.

util-linux
==
On 27th of September util-linux v2.24 RC will probably be released. This
release supports the identification of bcache superblocks in libblkid,
actually integrating and obsoleting probe-bcache. Because of this udev
rules for bcache can be simplified because they only need blkid. Of
course this only applies to systems where util-linux v2.24 RC (or
higher) actually is installed, otherwise probe-bcache is still needed.

Dracut
==
Since version 032 Dracut already had bcache support. Since version 033
it adds support for util-linux v2.24 RC, so even without (obsoleted)
probe-bcache it is able to identify bcache using blkid. Additionally
Dracut benefits from blkid being able to identify bcache, because it
uses blkid to identify all necessary kernel modules automatically, so no
-N option is needed anymore.

LVM2

With the release of v2_01_102 LVM2 now accepts Physical Volumes on
bcache by default. This simplifies the creation of initramfs (by Dracut)
because no specific LVM2 option (--lvmconf) needs to be passed to
Dracut.For the user this means that updating a kernel just works out of
the box!

bcache-tools

The bcache-tools package is available in Fedora 20. I plan to build an
updated package that no longer includes probe-bcache when the new
util-linux is released.

Anaconda

Anaconda (the Fedora installer) does not support bcache yet. This is
planned for Fedora 20. This is important when installing Fedora on a
system and having your root filesystem on bcache. Althought other
Distro's don't use Anaconda, I guess their installers also need to be
changed in some way to supportbcache.

Currently having Fedora installed with your root Filesystem on bcache is
possible, but It's done in a fewsteps:
1. Install Fedora using Anaconda without using bcache, but create an
extra partition to supportan alternate root FS
2. From the running system build a bcache device using the extra
partition. Copy the current root FS to the bcache root FS
3. Reboot your system in the bcache root FS, and reclaim the spaces used
by the non-bcache root partition

More information can be found below, related to the SSD Cache Fedora
test day.

The SSD Cache Fedora test day
=
On 13th of October there's an SSD Cache Fedora test day: see the Wiki
page https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache. This
page is work in progress, any feedback is welcome. People interested in
testing are invited to participate on 13th of October.

When there's anything new toreport, I'll keep you posted.

Rolf Fokkens


-- 
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-tools and bcache support in other linux packages

[Rolf Fokkens]

Hi,

Like I did on the 14th on the linux-bcache list I'd like to send an 
update on the progress of bcache related packages. While focussing on 
Fedora packaging of bcache-tools, I had some good collaboration with 
other packagers resulting in improved bcache support in other packages 
as well. Other Linux distro's may benefit from these updated packages too.


util-linux
==
On 27th of September util-linux v2.24 RC will probably be released. This 
release supports the identification of bcache superblocks in libblkid, 
actually integrating and obsoleting probe-bcache. Because of this udev 
rules for bcache can be simplified because they only need blkid. Of 
course this only applies to systems where util-linux v2.24 RC (or 
higher) actually is installed, otherwise probe-bcache is still needed.


Dracut
==
Since version 032 Dracut already had bcache support. Since version 033 
it adds support for util-linux v2.24 RC, so even without (obsoleted) 
probe-bcache it is able to identify bcache using blkid. Additionally 
Dracut benefits from blkid being able to identify bcache, because it 
uses blkid to identify all necessary kernel modules automatically, so no 
-N option is needed anymore.


LVM2

With the release of v2_01_102 LVM2 now accepts Physical Volumes on 
bcache by default. This simplifies the creation of initramfs (by Dracut) 
because no specific LVM2 option (--lvmconf) needs to be passed to 
Dracut.For the user this means that updating a kernel just works out of 
the box!


bcache-tools

The bcache-tools package is available in Fedora 20. I plan to build an 
updated package that no longer includes probe-bcache when the new 
util-linux is released.


Anaconda

Anaconda (the Fedora installer) does not support bcache yet. This is 
planned for Fedora 20. This is important when installing Fedora on a 
system and having your root filesystem on bcache. Althought other 
Distro's don't use Anaconda, I guess their installers also need to be 
changed in some way to supportbcache.


Currently having Fedora installed with your root Filesystem on bcache is 
possible, but It's done in a fewsteps:
1. Install Fedora using Anaconda without using bcache, but create an 
extra partition to supportan alternate root FS
2. From the running system build a bcache device using the extra 
partition. Copy the current root FS to the bcache root FS
3. Reboot your system in the bcache root FS, and reclaim the spaces used 
by the non-bcache root partition


More information can be found below, related to the SSD Cache Fedora 
test day.


The SSD Cache Fedora test day
=
On 13th of October there's an SSD Cache Fedora test day: see the Wiki 
page https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache. This 
page is work in progress, any feedback is welcome. People interested in 
testing are invited to participate on 13th of October.


When there's anything new toreport, I'll keep you posted.

Rolf Fokkens
--
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: SSD caching

[Rolf Fokkens]

Things are progressing well with the SSD cache feature, so I'd like to 
give a brief update.


dm-cache  bcache
-
Initially both dm-cache and bcache were in scope to provide users with 
the SSD caching feature in Fedora 20. Both are supported by the latest 
Linux kernels, but unfortunately userspace tooling (lvm2) for dm-cache 
still requires considerable effort so focus has been te have bcache in F20.


System wide or Self contained?
--
For F20 the intention was to have SSD cache Self contained, and to have 
it System wide in F21. Looks like we're ahead of schedule! Thanks to the 
great cooperation of community members responsible for other Fedora 
packages, we may see a well integrated bcache implementation in F20. 
Because bcache is quite new we should however consider it Experimental!


What works?
---
Currently I'm running my root FS on bcache. My system runs great. Both 
kernel updates and other updates (in F20 updates-testing*) work without 
any problems. This means dat a working intramdisk is created by dracut, 
which in turn means that util-linux (blkid) detects bcache. To 
'complicate' testing I have the root FS on lvm (which is on bcache)! And 
as a bonus of course I'm experiencing a nice performance :-)


Because Anaconda doesn't support bcache (yet) creating a running system 
with root FS on bcache requires some manual work, but once it's 
running it's running well!


*) some packages are not yet in updates testing, details below.

Testing
---
Thanks to Igor Gnatekno a Fedora Test day is planned 13th of october: 
https://fedorahosted.org/fedora-qa/ticket/415. To support this a Wiki 
page (work in progress) is maintained: 
https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache. Anybody 
interested in testing is welcome!


util-linux
--
libblkid in util-linux v2.24 will support bcache, which means that both 
blkid and wipefs will detect (and wipe) bcache. Currently util-linux 
v2.23 is available, but v2.24 rc will be in F20 (thanks Karel Zak). To 
test bcache I'm running a patched v2.23 that already has the planned 
support for bcache.


bache-tools
---
The bcache-tools package is available in F20 updates-testing, and seems 
to be in pretty good shape (thank you reviewers, thanks Hans de Goede). 
Currently bcache-tools includes a bcache-probe utility, but that may no 
longer be in the package when F20 is released because it's obsoleted by 
blkid in util-linux v2.24.


dracut
--
Dracut now has a bcache module to build initramfs(thanks Harold Hoyer). 
This works very well, but it currently needs the -N option. When 
util-linux v2.24 is released dracut will detect bcache and be able to 
operate without the -N option.


LVM2

LVM2 does normally not accept a bcache device as PV (physical volume). A 
small 'one-line' patch can fix this, but the lvm2 people are working on 
other lvm2 stuff. I hope Alasdair Kergon will be able to get this simple 
change in LVM2.


If not, users can manually configure LVM2 to accept bcache devices as PV 
by making a small change to their /etc/lvm/lvm.conf. To build a working 
initramfs users need to manually pass the --lvmconf option to dracut, so 
a kernel upgrade won't work out-of-the-box.

mailto:a...@redhat.com
I tested bcache by using a patched LVM2 that accepts bcache as a PV, 
hoping the patch will be in F20.


Anaconda

Currently the team is very busy getting anaconda ready for F20, and 
including bcache support may require considerable effort. Hopefully 
anaconda has bcache support in F21.




More details: https://bugzilla.redhat.com/show_bug.cgi?id=998543

-- 
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: polkit rules for virt administration

[Rolf Fokkens]

Hi,

Op 17 sep. 2013 om 04:49 heeft William Brown will...@firstyear.id.au het 
volgende geschreven:

 
 Was just wondering if any more discussion or action had been taken with
 this. Would be good to see included in F20.
 
 -- 
 Sincerely,
 
 William Brown
 
 pgp.mit.edu
 http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2
 
 
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: polkit rules for virt administration

[Rolf Fokkens]

I agree, this is useful. I'm currently also having my own polkit rules to 
achieve this. I'm currently using the groep wheel for this, but that's not the 
right choice.

Would be good to have a solution in f20.

Rolf
Op 17 sep. 2013 om 05:55 heeft Rolf Fokkens r...@rolffokkens.nl het volgende 
geschreven:

 Hi,
 
 Op 17 sep. 2013 om 04:49 heeft William Brown will...@firstyear.id.au het 
 volgende geschreven:
 
 
 Was just wondering if any more discussion or action had been taken with
 this. Would be good to see included in F20.
 
 -- 
 Sincerely,
 
 William Brown
 
 pgp.mit.edu
 http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2
 
 
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Dracut, Anaconda bcache

[Rolf Fokkens]

Hi!

The following change has been accepted for F20: 
https://fedorahosted.org/fesco/ticket/1145


More details: https://bugzilla.redhat.com/show_bug.cgi?id=998543

For F20 it'll be SelfContained, but for F21 the plans are to make it 
SystemWide.


I'm focussing currently on bcache, and I think bcache-tools is getting 
into shape for F20 and non-root filesystems will work fine. To prepare 
for F21 I'm initiating some initial reseach, specifically related to 
Anaconda and Dracut, because to my understanding both Anaconda and 
Dractut need to be able to handle bcache when users want to have a root 
filesystem on bcache.


For both Dracut and Anaconda I created Fedora bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1003207
https://bugzilla.redhat.com/show_bug.cgi?id=1003208

I don't have a good overview yet, so any feedback is welcome on how to 
proceed, .


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

bcache-tools: How and when loading kernel module bcache

[Rolf Fokkens]

Hi all,

I'm working on packaging bcache-tools, see 
https://bugzilla.redhat.com/show_bug.cgi?id=999690


I'd like some advice on when and how to load the bcache kernel module.

The easiest way for now is to have a file 
/etc/modules-load.d/bcache.conf in the package which makes systemd load 
the module. This works when using bcache for some filesystems, but it 
will also load the bcache module when no bcache is actually used. So, is 
this the right approach?


An alternative would be to have the udev bcache.rules file load the 
kernel module whenever a bcache block device is spotted. Is this better?


Any feedback is is welcome,

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

Self Introduction

[Rolf Fokkens]

Hi All,

Having a great interrest in combining both the qualities of SSD's 
(speed) and the qualities of HDD's (capacity) I added the following 
change: https://fedoraproject.org/wiki/Changes/SSD_cache


Since this change was accepted, I now have to really do something :-) As 
a result here's my first review request: 
https://bugzilla.redhat.com/show_bug.cgi?id=999690


I have to admit that my interest in the combination of SSD's and HDD's 
is primarily a user's interest. I'm not an experienced Fedora developer, 
but in general I built all kinds of software in the past. I hope that 
I'm able to contribute, and that in the end I'm able to experience the 
great performance of SSD's in combination with the storage capacity of 
HDD's.


Rolf Fokkens
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct