ok, thats interesting. I had issues before this crash where files were
being garbled. I followed what I thought was the correct procedure for
erasure coded pool with cache tier:
> ceph osd pool create ECpool 800 800 erasure default
> ceph osd pool create CachePool 4096 4096
> ceph osd tier add ECpool CachePool
> ceph osd tier cache-mode CachePool readonly
> ceph osd tier set-overlay ECpool CachePool
> ceph osd pool create cephfs_metadata 4096 4096
> ceph fs new cephfs cephfs_metadata ECpool
Is my mistake the last command above? should the ceph fs new be given
the CachePool and not the ECpool?
thanks
On 29/05/15 11:17, John Spray wrote:
On 29/05/2015 09:46, Peter Tiernan wrote:
-16> 2015-05-29 09:28:23.106541 7f78c53a9700 10 mds.0.objecter in
handle_osd_op_reply
-15> 2015-05-29 09:28:23.106543 7f78c53a9700 7 mds.0.objecter
handle_osd_op_reply 28 ondisk v 0'0 uv 0 in 11.5ce99960 attempt 1
-14> 2015-05-29 09:28:23.106546 7f78c53a9700 10 mds.0.objecter op
0 rval -95 len 0
-13> 2015-05-29 09:28:23.106552 7f78c53a9700 5 mds.0.objecter 1
unacked, 1 uncommitted
-12> 2015-05-29 09:28:23.106958 7f78c52a8700 10 mds.0.objecter
ms_dispatch 0x3e2e000 osd_op_reply(29 10000000064.00000004 [trimtrunc
2@0] v0'0 uv0 ondisk = -95 ((95) Operation not supported)) v6
-11> 2015-05-29 09:28:23.106971 7f78c52a8700 10 mds.0.objecter in
handle_osd_op_reply
-10> 2015-05-29 09:28:23.106973 7f78c52a8700 7 mds.0.objecter
handle_osd_op_reply 29 ondisk v 0'0 uv 0 in 11.50e84eb2 attempt 1
-9> 2015-05-29 09:28:23.106976 7f78c52a8700 10 mds.0.objecter op
0 rval -95 len 0
-8> 2015-05-29 09:28:23.106980 7f78c52a8700 5 mds.0.objecter 1
unacked, 0 uncommitted
-7> 2015-05-29 09:28:23.107296 7f78c69bf700 10 mds.0.objecter
ms_dispatch 0x3e2e000 osd_op_reply(30 1.00000000 [omap-get-header
0~0,omap-get-vals 0~16] v0'0 uv1 ondisk = 0) v6
-6> 2015-05-29 09:28:23.107307 7f78c69bf700 10 mds.0.objecter in
handle_osd_op_reply
-5> 2015-05-29 09:28:23.107309 7f78c69bf700 7 mds.0.objecter
handle_osd_op_reply 30 ondisk v 0'0 uv 1 in 13.6b2cdaff attempt 0
-4> 2015-05-29 09:28:23.107311 7f78c69bf700 10 mds.0.objecter op
0 rval 0 len 222
-3> 2015-05-29 09:28:23.107313 7f78c69bf700 10 mds.0.objecter op
1 rval 0 len 4
-2> 2015-05-29 09:28:23.107315 7f78c69bf700 10 mds.0.objecter op
1 handler 0x3e316b0
-1> 2015-05-29 09:28:23.107321 7f78c69bf700 5 mds.0.objecter 0
unacked, 0 uncommitted
0> 2015-05-29 09:28:23.108478 7f78cb4d9700 -1 mds/MDCache.cc: In
function 'virtual void C_IO_MDC_TruncateFinish::finish(int)' thread
7f78cb4d9700 time 2015-05-29 09:28:23.107027
mds/MDCache.cc: 5974: FAILED assert(r == 0 || r == -2)
OK, so you have "Operation not supported" coming out of RADOS. That
usually means you've got CephFS trying to use an erase coded pool
directly (doesn't work) rather than via a replicated cache pool (does
work).
You may have found that the filesystem appeared to work up to a point
if you were only writing and not modifying.
John
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
