I had a similar issue where files were padded out to the length of
ceph.dir.layout.stripe_unit (see email entitled "Issue with Ceph padding
files out to ceph.dir.layout.stripe_unit size" on this list). I never found
a solution, but I can say that I am currently running 10.2.6 and haven't
seen the i
This seems like an expected behavior of any filesystem that isn't
journaling data writes but are instead just journaling metadata
updates (for speed reasons). On the start of the append operation, the
file metadata is updated with the new length but the data isn't
written to disk before you hard-re
I tried the following command but was presented w/ an error.
cephadmin@cephdeploy:~$ ceph_erasure_code_benchmark technique=reed_sol_van
-p=jerasure erasure-code-directory=/usr/local/lib/ceph/erasure-code/ -P k=8
-P m=3 -S 1048576 -i 50
load dlopen(/usr/local/lib/ceph/erasure-code/libec_=jerasure.
Pretty much says it all. 1GB test file copy to local:
$ time cp /mnt/ceph-kernel-driver-test/test.img .
real 2m50.063s
user 0m0.000s
sys 0m9.000s
$ time cp /mnt/ceph-fuse-test/test.img .
real 0m3.648s
user 0m0.000s
sys 0m1.872s
Yikes. The kernel driver averages ~5MB and the fuse driver average
Hmm pretty odd. When I ran test on ceph kernel vs ceph fuse , FUSE has always
been slower for both read and writes.
Try using tools like fio to run IO test with directIO(bypass system cache)
--
Deepak
On Apr 8, 2017, at 4:50 PM, Kyle Drake
mailto:k...@kyledrake.net>> wrote:
Pretty much says i
