:doc: Consolidated file system recommendations.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>

diff --git a/doc/config-cluster/file-system-recommendations.rst b/doc/config-cluster/file-system-recommendations.rst
index 93f52d678babf3f3a744fb70c34e7e7e35170de4..b498dc50a8f22118a2d53d1d2b5832c420d8a757 100644 (file)
--- a/doc/config-cluster/file-system-recommendations.rst
+++ b/doc/config-cluster/file-system-recommendations.rst
@@ -2,6 +2,9 @@
  Hard Disk and File System Recommendations
 ===========================================
 
+Hard Disk Prep
+==============
+
 Ceph aims for data safety, which means that when the application receives notice
 that data was written to the disk, that data was actually written to the disk.
 For old kernels (<2.6.33), disable the write cache if the journal is on a raw
@@ -16,6 +19,10 @@ disk, and a separate disk(s) for data. If you run data and an operating system
 on a single disk, create a separate partition for your data before configuring
 your OSD cluster.
 
+
+File Systems
+============
+
 Ceph OSDs depend on the Extended Attributes (XATTRs) of the underlying file
 system for:
 
@@ -54,3 +61,41 @@ add the following line to the ``[osd]`` section of your ``ceph.conf`` file. ::
    file system of the Ceph team in the long run, but ``xfs`` is currently more
    stable than ``btrfs``.  If you only plan to use RADOS and ``rbd`` without
    snapshots and without ``radosgw``, the ``ext4`` file system should work just fine.
+
+FS Background Info
+==================
+
+Before ``ext3``, ``ReiserFS`` was the only journaling file system available for
+Linux. However, ``ext3`` doesn't provide Extended Attribute (XATTR) support.
+While ``ext4`` provides XATTR support, it only allows XATTRs up to 4kb. The 
+4kb limit is not enough for RADOS GW ACLs, snapshots, and other features. As of
+version 0.45, Ceph provides a ``leveldb`` feature for ``ext4`` file systems 
+that stores XATTRs in excess of 4kb in a ``leveldb`` database.  
+
+The ``XFS`` and ``btrfs`` file systems provide numerous advantages in highly 
+scaled data storage environments when `compared`_ to ``ext3`` and ``ext4``.
+Both ``XFS`` and ``btrfs`` are `journaling file systems`_, which means that
+they are more robust when recovering from crashes, power outages, etc. These
+filesystems journal all of the changes they will make before performing writes.
+
+``XFS`` was developed for Silicon Graphics, and is a mature and stable
+filesystem. By contrast, ``btrfs`` is a relatively new file system that aims
+to address the long-standing wishes of system administrators working with 
+large scale data storage environments. ``btrfs`` has some unique features
+and advantages compared to other Linux filesystems. 
+
+``btrfs`` is a `copy-on-write`_ filesystem. It supports file creation
+timestamps and checksums that verify metadata integrity, so it can detect
+bad copies of data and fix them with the good copies. The copy-on-write 
+capability means that ``btrfs`` can support snapshots that are writable.
+``btrfs`` supports transparent compression and other features.
+
+``btrfs`` also incorporates multi-device management into the file system,
+which enables you to support heterogeneous disk storage infrastructure,
+data allocation policies. The community also aims to provide ``fsck``, 
+deduplication, and data encryption support in the future. This compelling 
+list of features makes ``btrfs`` the ideal choice for Ceph clusters.
+
+.. _copy-on-write: http://en.wikipedia.org/wiki/Copy-on-write
+.. _compared: http://en.wikipedia.org/wiki/Comparison_of_file_systems
+.. _journaling file systems: http://en.wikipedia.org/wiki/Journaling_file_system