projects / ceph.git / blame
| Commit | Line | Data |
|---|---|---|
| 7c673cae FG |
1 | =========================================== |
| 2 | Hard Disk and File System Recommendations | |
| 3 | =========================================== | |
| 4 | ||
| 5 | .. index:: hard drive preparation | |
| 6 | ||
| 7 | Hard Drive Prep | |
| 8 | =============== | |
| 9 | ||
| 10 | Ceph aims for data safety, which means that when the :term:`Ceph Client` | |
| 11 | receives notice that data was written to a storage drive, that data was actually | |
| 12 | written to the storage drive. For old kernels (<2.6.33), disable the write cache | |
| 13 | if the journal is on a raw drive. Newer kernels should work fine. | |
| 14 | ||
| 15 | Use ``hdparm`` to disable write caching on the hard disk:: | |
| 16 | ||
| 17 | sudo hdparm -W 0 /dev/hda 0 | |
| 18 | ||
| 19 | In production environments, we recommend running a :term:`Ceph OSD Daemon` with | |
| 20 | separate drives for the operating system and the data. If you run data and an | |
| 21 | operating system on a single disk, we recommend creating a separate partition | |
| 22 | for your data. | |
| 23 | ||
| 24 | .. index:: filesystems | |
| 25 | ||
| 26 | Filesystems | |
| 27 | =========== | |
| 28 | ||
| 29 | Ceph OSD Daemons rely heavily upon the stability and performance of the | |
| 30 | underlying filesystem. | |
| 31 | ||
| 32 | Recommended | |
| 33 | ----------- | |
| 34 | ||
| 35 | We currently recommend ``XFS`` for production deployments. | |
| 36 | ||
| 7c673cae FG |
37 | Not recommended |
| 38 | --------------- | |
| 39 | ||
| 224ce89b WB |
40 | We recommand *against* using ``btrfs`` due to the lack of a stable |
| 41 | version to test against and frequent bugs in the ENOSPC handling. | |
| 42 | ||
| 7c673cae FG |
43 | We recommend *against* using ``ext4`` due to limitations in the size |
| 44 | of xattrs it can store, and the problems this causes with the way Ceph | |
| 45 | handles long RADOS object names. Although these issues will generally | |
| 46 | not surface with Ceph clusters using only short object names (e.g., an | |
| 47 | RBD workload that does not include long RBD image names), other users | |
| 48 | like RGW make extensive use of long object names and can break. | |
| 49 | ||
| 50 | Starting with the Jewel release, the ``ceph-osd`` daemon will refuse | |
| 51 | to start if the configured max object name cannot be safely stored on | |
| 52 | ``ext4``. If the cluster is only being used with short object names | |
| 53 | (e.g., RBD only), you can continue using ``ext4`` by setting the | |
| 54 | following configuration option:: | |
| 55 | ||
| 56 | osd max object name len = 256 | |
| 57 | osd max object namespace len = 64 | |
| 58 | ||
| 59 | .. note:: This may result in difficult-to-diagnose errors if you try | |
| 60 | to use RGW or other librados clients that do not properly | |
| 61 | handle or politely surface any resulting ENAMETOOLONG | |
| 62 | errors. |