It turns out the permission problem.
When I change to ceph.admin, I can read the file, and the file content
seems garbage.
Best regards,
On 2015年05月01日 02:07, Gregory Farnum wrote:
The not permitted bit usually means that your client doesn't have
access permissions to the data pool in use.
I'm not sure why it would be getting aborted without any output though
— is there any traceback at all in the logs? A message about the
OOM-killer zapping it or something?
-Greg
On Thu, Apr 30, 2015 at 1:45 AM, flisky <yinjifeng@xxxxxxxxxxx> wrote:
Sorry，I cannot reproduce the "Operation not permitted" log
Here is a small portion of log with "debug_client = 20/20"
==========================================================
-22> 2015-04-30 16:29:12.858309 7fe9757f2700 10 client.58272 check_caps
on 10000000015.head(ref=2 ll_ref=10 cap_refs={} open={1=1} mode=100664
size=119/0 mtime=2015-04-20 14:14:57.961482 caps=pAsLsXsFscr(0=pAsLsXsFscr)
objectset[10000000015 ts 0/0 objects 0 dirty_or_tx 0] parents=0x7fe968022980
0x7fe968021c30) wanted pFscr used - is_delayed=1
-21> 2015-04-30 16:29:12.858326 7fe9757f2700 10 client.58272 cap mds.0
issued pAsLsXsFscr implemented pAsLsXsFscr revoking -
-20> 2015-04-30 16:29:12.858333 7fe9757f2700 10 client.58272 send_cap
10000000015.head(ref=2 ll_ref=10 cap_refs={} open={1=1} mode=100664
size=119/0 mtime=2015-04-20 14:14:57.961482 caps=pAsLsXsFscr(0=pAsLsXsFscr)
objectset[10000000015 ts 0/0 objects 0 dirty_or_tx 0] parents=0x7fe968022980
0x7fe968021c30) mds.0 seq 1 used - want pFscr flush - retain
pAsxLsxXsxFsxcrwbl held pAsLsXsFscr revoking - dropping -
-19> 2015-04-30 16:29:12.858358 7fe9757f2700 15 client.58272 auth cap,
setting max_size = 0
-18> 2015-04-30 16:29:12.858368 7fe9757f2700 10 client.58272 _create_fh
10000000015 mode 1
-17> 2015-04-30 16:29:12.858376 7fe9757f2700 20 client.58272 trim_cache
size 14 max 16384
-16> 2015-04-30 16:29:12.858378 7fe9757f2700 3 client.58272 ll_open
10000000015.head 32768 = 0 (0x7fe95c0052c0)
-15> 2015-04-30 16:29:12.858385 7fe9757f2700 3 client.58272 ll_forget
10000000015 1
-14> 2015-04-30 16:29:12.858386 7fe9757f2700 20 client.58272 _ll_put
0x7fe968021c30 10000000015 1 -> 9
-13> 2015-04-30 16:29:12.858500 7fe974ff1700 20 client.58272 _ll_get
0x7fe968021c30 10000000015 -> 10
-12> 2015-04-30 16:29:12.858503 7fe974ff1700 3 client.58272 ll_getattr
10000000015.head
-11> 2015-04-30 16:29:12.858505 7fe974ff1700 10 client.58272 _getattr
mask pAsLsXsFs issued=1
-10> 2015-04-30 16:29:12.858509 7fe974ff1700 10 client.58272 fill_stat on
10000000015 snap/devhead mode 0100664 mtime 2015-04-20 14:14:57.961482 ctime
2015-04-20 14:14:57.960359
-9> 2015-04-30 16:29:12.858518 7fe974ff1700 3 client.58272 ll_getattr
10000000015.head = 0
-8> 2015-04-30 16:29:12.858525 7fe974ff1700 3 client.58272 ll_forget
10000000015 1
-7> 2015-04-30 16:29:12.858526 7fe974ff1700 20 client.58272 _ll_put
0x7fe968021c30 10000000015 1 -> 9
-6> 2015-04-30 16:29:12.858536 7fe9577fe700 3 client.58272 ll_read
0x7fe95c0052c0 10000000015 0~4096
-5> 2015-04-30 16:29:12.858539 7fe9577fe700 10 client.58272 get_caps
10000000015.head(ref=3 ll_ref=9 cap_refs={} open={1=1} mode=100664
size=119/0 mtime=2015-04-20 14:14:57.961482 caps=pAsLsXsFscr(0=pAsLsXsFscr)
objectset[10000000015 ts 0/0 objects 0 dirty_or_tx 0] parents=0x7fe968022980
0x7fe968021c30) have pAsLsXsFscr need Fr want Fc but not Fc revoking -
-4> 2015-04-30 16:29:12.858561 7fe9577fe700 10 client.58272 _read_async
10000000015.head(ref=3 ll_ref=9 cap_refs={2048=1} open={1=1} mode=100664
size=119/0 mtime=2015-04-20 14:14:57.961482 caps=pAsLsXsFscr(0=pAsLsXsFscr)
objectset[10000000015 ts 0/0 objects 0 dirty_or_tx 0] parents=0x7fe968022980
0x7fe968021c30) 0~4096
-3> 2015-04-30 16:29:12.858575 7fe9577fe700 10 client.58272 max_byes=0
max_periods=4
-2> 2015-04-30 16:29:12.858692 7fe9577fe700 5 client.58272 get_cap_ref
got first FILE_CACHE ref on 10000000015.head(ref=3 ll_ref=9
cap_refs={1024=0,2048=1} open={1=1} mode=100664 size=119/0 mtime=2015-04-20
14:14:57.961482 caps=pAsLsXsFscr(0=pAsLsXsFscr) objectset[10000000015 ts 0/0
objects 1 dirty_or_tx 0] parents=0x7fe968022980 0x7fe968021c30)
-1> 2015-04-30 16:29:12.867657 7fe9797fa700 10 client.58272
ms_handle_connect on 172.16.3.149:6823/982446
0> 2015-04-30 16:29:12.872787 7fe97bfff700 -1 *** Caught signal
(Aborted) **
On 2015年04月30日 16:21, flisky wrote:
When I read the file through the ceph-fuse, the process crashed.
Here is the log -
====================
terminate called after throwing an instance of
'ceph::buffer::end_of_buffer'
what(): buffer::end_of_buffer
*** Caught signal (Aborted) **
in thread 7fe0814d3700
ceph version 0.94.1 (e4bfad3a3c51054df7e537a724c8d0bf9be972ff)
1: (()+0x249805) [0x7fe08670b805]
2: (()+0x10d10) [0x7fe085c39d10]
3: (gsignal()+0x37) [0x7fe0844d3267]
4: (abort()+0x16a) [0x7fe0844d4eca]
5: (__gnu_cxx::__verbose_terminate_handler()+0x16d) [0x7fe084de706d]
6: (()+0x5eee6) [0x7fe084de4ee6]
7: (()+0x5ef31) [0x7fe084de4f31]
8: (()+0x5f149) [0x7fe084de5149]
9: (ceph::buffer::list::substr_of(ceph::buffer::list const&, unsigned
int, unsigned int)+0x24b) [0x7fe08688993b]
10: (ObjectCacher::_readx(ObjectCacher::OSDRead*,
ObjectCacher::ObjectSet*, Context*, bool)+0x1423) [0x7fe0866c6b73]
11: (ObjectCacher::C_RetryRead::finish(int)+0x20) [0x7fe0866cd870]
12: (Context::complete(int)+0x9) [0x7fe086687eb9]
13: (void finish_contexts<Context>(CephContext*, std::list<Context*,
std::allocator<Context*> >&, int)+0xac) [0x7fe0866ca73c]
14: (ObjectCacher::bh_read_finish(long, sobject_t, unsigned long,
long, unsigned long, ceph::buffer::list&, int, bool)+0x29e)
[0x7fe0866bfd2e]
15: (ObjectCacher::C_ReadFinish::finish(int)+0x7f) [0x7fe0866cc85f]
16: (Context::complete(int)+0x9) [0x7fe086687eb9]
17: (C_Lock::finish(int)+0x29) [0x7fe086688269]
18: (Context::complete(int)+0x9) [0x7fe086687eb9]
19: (Finisher::finisher_thread_entry()+0x1b4) [0x7fe08671f184]
20: (()+0x76aa) [0x7fe085c306aa]
21: (clone()+0x6d) [0x7fe0845a4eed]
=============================
Some part may be interesting -
-11> 2015-04-30 15:55:59.063828 7fd6a816c700 10 --
172.30.11.188:0/10443 >> 172.16.3.153:6820/1532355 pipe(0x7fd6740344c0
sd=8 :58596 s=2 pgs=3721 cs=1 l=1 c=0x7fd674038760).reader got message 1
0x7fd65c001940 osd_op_reply(1 10000000019.00000000 [read 0~4390] v0'0
uv0 ack = -1 ((1) Operation not permitted)) v6
-10> 2015-04-30 15:55:59.063848 7fd6a816c700 1 --
172.30.11.188:0/10443 <== osd.9 172.16.3.153:6820/1532355 1 ====
osd_op_reply(1 10000000019.00000000 [read 0~4390] v0'0 uv0 ack = -1 ((1)
Operation not permitted)) v6 ==== 187+0+0 (689339676 0 0) 0x7fd65c001940
con 0x7fd674038760
And the cephfs-journal seems okay.
Could anyone tell me why it is happening?
And more important, does Ceph offer any tool to export a cephfs data
from underlaid pools?
Thanks very much!
_______________________________________________
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
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
