From Fedora Project Wiki
Line 129: Line 129:
== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: (What to do?  Who will do it?) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
   * LVM2: the change is present in upstream
   * LVM2: Changes are already present upstream.  If severe bugs are found, cache can be disabled here.
   * Dracut: there is already hardcoded dm-cache installation. If the detection is in done in time it will work as is.
   * Dracut: There is already a hardcoded dm-cache installation. If the detection is not done in time, it will work as is.
   * Anaconda: cache will work even without UI except it will not be configurable by regular users without using command line.
   * Anaconda: Cache will work even without UI except it will not be configurable by regular users without using command line.  Users can also setup cache LVs after installation.
   * LVM2: we will need an ability to drop the cache shall the cache device fail or become corrupted (this can be done using Live CD.)
   * LVM2: We will need an ability to drop the cache should the cache device fail or become corrupted(This can be done using Live CD.)
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: beta freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: beta freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Revision as of 19:32, 8 April 2014

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.


LVM Cache Logical Volumes

Summary

LVM can now use fast block devices (e.g. SSDs and PCIe Flash) to improve the performance of larger but slower block devices. These hierarchical or layered logical volumes are called "Cache Logical Volumes" in LVM.

Owner

Current status

  • Targeted release: Fedora 21
  • Last updated: (DATE)
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

LVM is now capable of using fast block devices (e.g. SSDs) as write-back or write-though caches for larger slower block devices. Users can create cache logical volumes to improve the performance of their existing logical volumes or create new cache logical volumes composed of a small and fast device coupled with a large and slow device. These cache logical volumes can be used with most LVM segment types, including RAID 1/4/5/6/10, linear, stripe and thin pools.

Benefit to Fedora

Users will have the advantage of fast block device speeds with the capacity of larger but slower block devices.

Scope

  • Proposal owners:
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)

Upgrade/compatibility impact

  • Nothing changes for users following update path.
  • The logical volumes using cache will become unavailable from systems using older kernels and LVM. The cache will have to be dropped to grant access for those legacy systems.

How To Test

To test the feature user will have to:

  • install the system with cache configured once the Anaconda UI is available
  • converting existing LVs to use SSD cache once the LVM package is updated to include latest upstream patches

An SSD or other fast block device is recommended to actually increase the speed but the feature will be testable without one as the user may create a cache device from the data disk with effect of decreased performance.

Information on how to setup cache logical volumes can be found in the lvm(8) man page.

User Experience

Users will enjoy the increased speed of disk storage while keeping capacity of HDD.

Dependencies

  • Anaconda: Implementation of UI
  • Dracut: Module to Detect and install required configuration files and kernel modules

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)
 * LVM2:  Changes are already present upstream.  If severe bugs are found, cache can be disabled here.
 * Dracut:  There is already a hardcoded dm-cache installation.  If the detection is not done in time, it will work as is.
 * Anaconda:  Cache will work even without UI except it will not be configurable by regular users without using command line.  Users can also setup cache LVs after installation.
 * LVM2:  We will need an ability to drop the cache should the cache device fail or become corrupted.  (This can be done using Live CD.)
  • Contingency deadline: beta freeze
  • Blocks release? No (not a System Wide Change), Yes/No
  • Blocks product? -

Documentation

  • Command line: Cache section of the upstream [lvm(8)] man page.

Release Notes