Hello Lars, > By not encrypting the entire OSD device, one becomes susceptible to > metadata analysis (on the file store), data exposure, etc. Agreed, filesystem-related metadata like mtime, ctime and size will be available. Alll data related to a RADOS object will be encrypted. This includes: * object name, * object data, * user attributes names, * user attributes values, * OMAP header content, * OMAP attributes names (keys), * OMAP values. Metadata of RADOS object that will be available: data size, OMAP header size, existence of user/OMAP attributes. For many use cases (eg. RBD) this isn't an issue. > I'd obviously be delighted to see this all sped up (and consume less > power), but as long as the system is fast enough to encrypt at > near-device speeds, this seems preferable. I can agree that in case of HDDs full disk encryption is an affordable solution. This is a consequence of relatively low throughput of a magnetic carrier in comparison to modern crypto performance. However, the status quo is challenged by proliferation of fast SSDs. It drives demand for crypto performance much higher. HW acceleration would become must-have. There are at least three approaches that can be combined to form a holistic solution: 1) minimizing amount of plaintext through per-poor granulation, 2) skipping repetitive encryption, 3) utilizing full performance of an accelerator. dm-crypt is not optimized for advanced HW accelerators. Using the same accelerator in different way gives more performance gain. In summary: expected performance benefits may justify introducing mechanism targeting those use cases where covering full set of filesystem metadata (ctime, mtime, size) isn't required. Best regards, Adam Kupczyk, Radoslaw Zarzynski -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
