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
 |