+++ This bug was initially created as a clone of Bug #998543 +++
This is a tracking bug for Change: SSD cache
For more details, see: http://fedoraproject.org//wiki/Changes/SSD_cache
Using recent kernel (3.9 and later) features for (fast) SSD caching of (slow) ordinary hard disks.
--- Additional comment from Rolf Fokkens on 2013-08-21 13:35:33 EDT ---
I'll build a bcache-tools RPM and a dm-cache-utils rpm (actually bcache-tools is already available here: bcache-tools-20130820-0.1.fc19.src.rpm).
I'll follow the procedure as described here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
--- Additional comment from Rolf Fokkens on 2013-08-24 11:51:34 EDT ---
Tried to create a dmcache-utils package as well (Bug 1000078) but it doesn't look really useful. So I'll focus on bcache-tools first. For that I still need a sponsor.
--- Additional comment from Rolf Fokkens on 2013-08-27 06:52:40 EDT ---
I closed Bug 1000078 since good userland support requires LVM2 to support dm-cache. Which will happen 'in the future', but F20 doesn't look feasible to me.
--- Additional comment from Rolf Fokkens on 2013-08-31 16:21:30 EDT ---
Create Bug 1003207 (bcache support for dracut) which is not blocking for F20, but probably will be blocking for F21.
--- Additional comment from Rolf Fokkens on 2013-08-31 16:25:06 EDT ---
Create Bug 1003208 (bcache support for anaconda) which is not blocking for F20, but probably will be blocking for F21.
--- Additional comment from Rolf Fokkens on 2013-09-09 04:18:18 EDT ---
Test day planned: https://fedorahosted.org/fedora-qa/ticket/415
Discussion at https://lists.fedoraproject.org/pipermail/devel/2013-July/185336.html
Please document this Change in the Release Notes.
Are you refering to http://fedoraproject.org/wiki/F20_Alpha_release_announcement?
Rolf, this is for members of the Fedora Docs project to track representation of your change in the Release Notes that are published at docs.fedoraproject.org and shipped as the fedora-releaste-notes rpm. You don't have to do anything for it, unless you want to. For your reference, we put content in https://fedoraproject.org/wiki/Category:Documentation_beats?rd=Docs/Beats to start, then a git repo later.
Not having to do anything is great :-)
The following may (or may not) be informational:
draft at https://git.fedorahosted.org/cgit/docs/release-notes.git/commit/?id=52418044ba7b521855a21905aa53462f64cc3b0d
As a suggestion I would also add http://bcache.evilpiepirate.org/ in the "Learn more..." paragraph.
You may also think about the title. I agree that the title "SSD caching for filesystems" may be best understood by most users, but all it really does is speedup the underlying block device (which may be an abstract thing to may users). And acceleration your filesystem is one of the applications, users may also want to accelerate a logical volume thats supports a VM.
So maybe the title could be "SSD caching for filesystems an block devices".
The Gentoo tutorial you link to has some warts (inaccuracies about block size and conversion, and an ugly initramfs script), and the kylemanna link is about dmcache not bcache. I'm going to be peeved if this documentation perpetuates the notion that existing devices can't be converted, by the way. Please add a link to https://github.com/g2p/blocks instead.
Rolf, Nimimo, thanks for looking this over. I've made some changes based on your input, and would appreciate your review.
For Fedora 20 the blocks utility is not a part of bcache-tools, so the text is not describing the Fedora 20 situation.
I would suggest the following text:
Fedora 20 offers experimental support for adding solid state drives (SSD's) as fast, transparent caches to traditional rotating storage (HDD's). Filesystems on the SSD cached block devices offer both the speed of SSD's and volume of HDD's. In Fedora 20 SSD caching can be added to fresh partitions. Support for adding SSD caching to existing standard partitions and LVM storage is planned for Fedora 20"
(In reply to Rolf Fokkens from comment #8)
> For Fedora 20 the blocks utility is not a part of bcache-tools, so the text
> is not describing the Fedora 20 situation.
I wondered about that. There's good information in that readme, but it might be better left out to avoid confusion.
> I would suggest the following text:
> Fedora 20 offers experimental support for adding solid state drives (SSD's)
> as fast, transparent caches to traditional rotating storage (HDD's).
> Filesystems on the SSD cached block devices offer both the speed of SSD's
> and volume of HDD's. In Fedora 20 SSD caching can be added to fresh
> partitions. Support for adding SSD caching to existing standard partitions
> and LVM storage is planned for Fedora 20"
So, we can make a fresh bcache device *now*, and we expect subsequent updates during the F20 cycle to allow adding cache to existing block devices?
My text should have been (typo) "Support for adding SSD caching to existing standard partitions and LVM storage is planned for Fedora 21" instead of "... Fedora 20". But it's OK to make it "Support for adding SSD caching to existing standard partitions and LVM storage is planned later during the Fedora 20 cycle"
Rolf clarified this for me here, and out of band - thanks.
`blocks` looks like a great utility, but I'm not comfortable boasting that Fedora offers it's functionality until `blocks` is formally packaged. I also don't want to give the impression that existing block devices can't be converted, but the integrity of the user's data is paramount. To that end, I've added this admonition that I hope addresses everyone's concerns:
Always back up your data before making low level changes, such as migrating to a bcache device. Until tools like <ulink url="https://github.com/g2p/blocks">blocks</ulink> are packaged for Fedora, users are advised to implement bcache by creating clean bcache devices and populating thier filesystems from a recent backup.
I checked out the latest fedora-release-notes package, looks good. Except for the link to
This link refers to dm-cache, which is an alternative to bcache. I think this link should not be there, because it will confuse users.
I've commented out that entry, thanks Rolf. It won't appear when next published.