Hello,
Ceph is not problem. Problem is that btrfs is not still production.But it's really up to you which filesystem you use.
Each filesystem has unique functions so you have to consider
them to get best performance from one of them.
Meaning that there would be no perfect filesystem.
On Sat, Aug 8, 2015 at 6:29 AM, Lionel Bouton <lionel+ceph@xxxxxxxxxxx> wrote:
Le 07/08/2015 22:05, Ben Hines a écrit :
> Howdy,
>
> The Ceph docs still say btrfs is 'experimental' in one section, but
> say it's the long term ideal for ceph in the later section. Is this
> still accurate with Hammer? Is it mature enough on centos 7.1 for
> production use?
>
> (kernel is 3.10.0-229.7.2.el7.x86_64 )
Difficult to say with distribution kernels, they may have patched their
kernels to fix some Btrfs issues or not (3.10.0 is more than 2 years
old) I wouldn't trust them myself.
We are converting our OSDs to Btrfs but we use recent kernel versions
(4.0.5 currently), we disabled Btrfs snapshots in ceph.conf (they are
too costly), created journals NOCOW (we will move them to SSDs
eventually) and developed our own defragmentation scheduler (Btrfs' own
autodefrag didn't perform well with Ceph when we started and we use the
btrfs defragmentation process to recompress data with zlib instead of
lzo as we mount OSD fs with compress=lzo for lower latency OSD writes).
In the above conditions, it is faster than XFS (~30% lower apply
latencies according to ceph osd perf), detects otherwise silent data
corruption (it caught some already) and provides ~10% additional storage
space thanks to lzo/zlib compression (most of our data is in the form of
already compressed files stored on RBD, actual gains obviously depend on
the data).
Best regards,
Lionel
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
--
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
