Hi Manuel!
I'm the one that submitted the the io500 results for Red Hat.
Ok, so a couple of things. First be aware that vendors are not required
to use any form of replication whatsoever for the IO500 test
submissions. Our results are thus using 1x replication. :) But! 2x
should only
Hi Dan,
Ah, that's fantastic regarding IOR. Have you tried the libcephfs
backend? That might be another route for easy testing (and at least on
our previous test setup I saw higher large sequential IO throughput with
it vs the kernel client). Lazy IO is definitely worth it if you have an
Hi Mark and all,
The key point is to consider your users' write requirements: do your
applications need to write concurrently to the same file from several
cephfs mounts? or does each job write to a separate file?
If your use-case is predominantly the latter, you'll have a lot of
success right
Hi Manuel,
I was the one that did Red Hat's IO500 CephFS submission. Feel free to
ask any questions you like. Generally speaking I could achieve 3GB/s
pretty easily per kernel client and up to about 8GB/s per client with
libcephfs directly (up to the aggregate cluster limits assuming
Hello,
no experience yet, but we are planning to do the same (although partly
NVME, partly spinning disks) for our upcoming cluster.
It's going to be rather focused on AI and ML applications that use
mainly GPUs, so the actual number of nodes is not going to be
overwhelming, probably around
