-Greg
On Tue, Jan 6, 2015 at 8:22 AM Lionel Bouton <lionel+ceph@xxxxxxxxxxx> wrote:
On 01/06/15 02:36, Gregory Farnum wrote:
> [...]
> "filestore btrfs snap" controls whether to use btrfs snapshots to keep
> the journal and backing store in check. WIth that option disabled it
> handles things in basically the same way we do with xfs.
>
> "filestore btrfs clone range" I believe controls how we do RADOS
> object clones. With this option enabled we use the btrfs clone range
> ioctl (? I think that's the interface); without it we do our own
> copies, again basically the same as we do with xfs.
Thanks for these informations I think I have a clearer picture now, the
next time I have the opportunity, I'll test BTRFS based OSD using manual
defragmentation (which I suspect might help performance) and if I still
get stability or performance problems I'll try disabling BTRFS specific
features.
My impression is that the core of BTRFS is stable and performant enough
for Ceph and that lzo compression and checksums are reasons enough to
use it instead of XFS but to get stable and performant OSDs some
features might have to be disabled. Hopefully we will expand our storage
network in the near future and I'll have the opportunity to test my
theories with very limited impact on stability and performance.
Quick follow-up question: can the options "filestore btrfs snap",
"filestore btrfs clone range" and "filestore journal parallel" be
modified on an existing/used OSD? I don't see why not for the last 2 as
COW being used or not doesn't change other filesystem semantics, but for
snapshots I'm not sure: at startup the available snapshots could have to
match a precise OSD filestore state which they wouldn't do after (for
example) disabling them and enabling them again.
Best regards,
Lionel
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
