CephFS subdatapool in practice?
Hello everyone, I am maintaining a cost-optimized Ceph cluster at Codeberg.org, that is serving a lot of small random IO (Git operations). Currently, the data is stored in a single CephFS pool on mixed SSD and HDD cluster, where the HDDs have a primary affinity of 0 to shift the reads to the SSDs. In a quest to further optimize our setup, I discovered the subdatapool feature described at https://github.com/TheJJ/ceph-cheatsheet#subdatapool (assigning multiple pools to a filesystem and using setfattr to allow writes in a certain folder to a separate pool). It feels like this would allow us to cut cost by moving certain directories with large files to a cheaper pool than that used for Git operations easily, without doing data migrations such as splitting data into multiple filesystems. Is anyone using this feature in production and can comment on it? Are there best practices regarding the usage of this feature? Any caveats to be aware of, such as overhead, latency, long-term maintainability? Since certain "interesting" features have been deprecated in the past, such as inline_data, I thought it would be better to ask here for feedback first. Thank you for the comments and have a nice day! Kind Regards Otto -- https://codeberg.org Codeberg e.V. – Arminiusstraße 2-4 – 10551 Berlin – Germany Registered at registration court Amtsgericht Charlottenburg VR36929.
Hi Otto, Am 1/17/25 um 20:29 schrieb Otto Richter (Codeberg e.V.):
Is anyone using this feature in production and can comment on it?
Are there best practices regarding the usage of this feature?
Any caveats to be aware of, such as overhead, latency, long-term maintainability?
File and directory layouts work very good in production. We are supporting several installations where that feature is used. Best is to start with an empty directory that gets 'layout' to the new pool as existing files will not be moved when changing that attribute. You will have to copy existing files to the new directory (and therefor the new pool). An "mv" will not change the pool. Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
On Thu, Jan 30, 2025 at 5:20 PM Otto Richter (Codeberg e.V.) <otto@codeberg.org> wrote:
Any caveats to be aware of, such as overhead, latency, long-term maintainability?
Since certain "interesting" features have been deprecated in the past, such as inline_data, I thought it would be better to ask here for feedback first.
The multiple-pools feature should exist forever. It's not complicated, brings a lot of utility, and is well tested and well-integrated with the rest of the system. :) None of that was true for inline data or cache tiering (which are the notable deprecated features I can recall offhand). -Greg
participants (3)
-
Gregory Farnum
-
Otto Richter (Codeberg e.V.)
-
Robert Sander