Each Ceph OSD (storage node) runs a custom object "file system" called EBOFS to store objects on locally attached disks. Although the current implementation of EBOFS is fully functional and already demonstrates promising performance (outperforming ext2/3, XFS, and ReiserFS under the workloads we anticipate), a range of improvements will be needed before it is ready for prime-time. These include:

Intelligent use of NVRAM for metadata and/or data journaling. A subset of write requests need to be synchronously committed to stable storage in order to ensure both good performance and strong file system integrity guarantees. Even a small amount of NVRAM (whether it is FLASH, MRAM, battery-backed DRAM, etc.) will enable very low latency for small writes while maintaining data safety. +
NVRAM for data journaling. Actually, this has been implemented, but is untested. EBOFS can utilize NVRAM to journal uncommitted requests much like WAFL does, significantly lowering write latency while facilitating more efficient disk scheduling, delayed allocation, and so forth.
RAID-aware allocation. Although we conceptually think of each OSD as a disk with an attached CPU, memory, and network interface, it is more likely that the actual OSDs deployed in production systems will be small to medium sized storage servers: a standard server with a locally attached array of SAS or SATA disks. In order to properly take advantage of the parallelism inherent in the use of multiple disks, the EBOFS allocator and disk scheduling algorithms have to be aware of the underlying structure of the array (be it RAID0, 1, 5, 10, etc.) in order to reap the performance and reliability rewards.

Native kernel client

- The prototype Ceph client is implemented as a user-space library. Although it can be mounted under Linux via the FUSE (file system in userspace) library, this incurs a significant performance penalty and limits Ceph's ability to provide strong POSIX semantics and consistency. A native Linux kernel implementation of the client in needed in order to properly take advantage of the performance and consistency features of Ceph. Because the client interaction with Ceph MDS and OSDs is more complicated than existing network file systems like NFS, this is a non-trivial endeavor. We are actively looking for experienced kernel programmers to help us out! + The prototype Ceph client is implemented as a user-space library. Although it can be mounted under Linux via the FUSE (file system in userspace) library, this incurs a significant performance penalty and limits Ceph's ability to provide strong POSIX semantics and consistency. A native Linux kernel implementation of the client in needed in order to properly take advantage of the performance and consistency features of Ceph. We are actively looking for experienced kernel programmers to help guide development in this area!

CRUSH tools

The Ceph project is always looking for more participants. If any of these projects sound interesting to you, please join our mailing list and drop us a line. +

The Ceph project is always looking for more participants. If any of these projects sound interesting to you, please join our mailing list. -Please feel free to contact us with any questions or comments. \ No newline at end of file +Please feel free to contact me with any questions or comments. -- 2.39.5