September 2019 - Dev - lists.ceph.io

by Sage Weil

Hi all, I've just merged https://github.com/ceph/ceph/pull/30191 to master, which adds assertions in the OSD that the result of any successful write is zero (or a negate error), and the output buffer is empty. This is preparation for adding support for >0 and non-empty buffers--but first we should verify no existing code is returning such data inadvertantly. If this turns up failures in the rgw, rbd, or cephfs suites, it's probably because a cls method is returning >0 or data for a write that the OSD was previously clearing out on its behalf. The fix is to just adjust the cls code to return 0 and no data. Thanks! sage

4 years, 8 months

1
0
0 0

09/12/2019 perf meeting is on!

by Mark Nelson

Hi Folks, Perf meeting is on in ~20 minutes! Today let's talk about Casey's propsal to avoid write stalls during bucket splitting, bluestore 4K min alloc size, and competing proposals for small objects in OMAP from Igor and Yanghonggang. Please feel free to add any other topics to the etherpad. See you there! Etherpad: https://pad.ceph.com/p/performance_weekly Bluejeans: https://bluejeans.com/908675367 Thanks, Mark

4 years, 8 months

1
0
0 0

Python annoying 2.7 depricated nagware

by Willem Jan Withagen

Hi, Just incase you got fedup with python 2.7 naging you about deprication: PYTHONWARNINGS=ignore:DEPRECATION; export PYTHONWARNINGS --WjW

4 years, 8 months

1
0
0 0

Re: Top China Cashmere Products New Designs

by zhongji818027255

4 years, 8 months

1
0
0 0

Re: Ski suit and Jackets

by yizi5159030833

4 years, 8 months

1
0
0 0

Re: Low PIM -153dBc/-161dBc RF passive components supplier --Bolite Electronic

by MarilynnGardemalGWJ

4 years, 8 months

1
0
0 0

cephfs - cannot start MDS

by Wyllys Ingersoll

I have a semi-corrupted cephfs filesystem (most directories are OK, but a few are broken). Trying to read or delete anything from the broken directories causes the MDS servers to crash, I have followed all of the disaster recovery steps, but I still cannot keep the MDS servers up and there are still corrupt directories in the FS. I can usually get the MDS to come back if I run "cephfs-data-scan scan_links" a couple of times, but it's not consistent. Any suggestions on how to resolve this issue? The mds crashes with the following traces in the log: -401> 2019-09-11 13:43:24.768 7fa71112b700 -1 log_channel(cluster) log [ERR] : bad backtrace on directory inode 0x1001476c473 -401> 2019-09-11 13:43:24.768 7fa71112b700 0 log_channel(cluster) do_log log to syslog -401> 2019-09-11 13:43:24.768 7fa71112b700 -1 log_channel(cluster) log [ERR] : bad backtrace on directory inode 0x100146dfe3b -401> 2019-09-11 13:43:24.768 7fa71112b700 0 log_channel(cluster) do_log log to syslog -401> 2019-09-11 13:43:24.768 7fa719aeb700 1 -- 10.10.30.115:6800/1442163404 <== osd.139 10.10.30.51:6800/142614 1 ==== osd_op_reply(84 100148d4cf3.00000000 [omap-get-header,omap-get-vals,getxattr (94)] v0'0 uv35566 ondisk = 0) v8 ==== 248+0+5722 (1809603995 0 3125985462) 0x8b5c340 con 0x5cc7800 -401> 2019-09-11 13:43:24.772 7fa71aaed700 1 -- 10.10.30.115:6800/1442163404 <== osd.76 10.10.30.55:6833/15548 1 ==== osd_op_reply(80 100146dfe3d.00000000 [omap-get-header,omap-get-vals,getxattr] v0'0 uv37154 ondisk = 0) v8 ==== 248+0+3667 (486108846 0 420775557) 0x2d30700 con 0x5bb8300 -401> 2019-09-11 13:43:24.772 7fa71112b700 -1 log_channel(cluster) log [ERR] : bad backtrace on directory inode 0x100146dfe3d .... -401> 2019-09-11 13:43:25.844 7fa71292e700 -1 /build/ceph-13.2.6/src/mds/Server.cc: In function 'void Server::_unlink_local(MDRequestRef&, CDentry*, CDentry*)' thread 7fa71292e700 time 2019-09-11 13:43:25.843472 /build/ceph-13.2.6/src/mds/Server.cc: 6599: FAILED assert(in->first <= straydn->first) ceph version 13.2.6 (7b695f835b03642f85998b2ae7b6dd093d9fbce4) mimic (stable) 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x14e) [0x7fa71f7a597e] 2: (()+0x2fab07) [0x7fa71f7a5b07] 3: (Server::_unlink_local(boost::intrusive_ptr<MDRequestImpl>&, CDentry*, CDentry*)+0x15e8) [0x548fa8] 4: (Server::handle_client_unlink(boost::intrusive_ptr<MDRequestImpl>&)+0x961) [0x549991] 5: (Server::handle_client_request(MClientRequest*)+0x49b) [0x563beb] 6: (Server::dispatch(Message*)+0x2fb) [0x5678cb] 7: (MDSRank::handle_deferrable_message(Message*)+0x434) [0x4da3c4] 8: (MDSRank::_dispatch(Message*, bool)+0x89b) [0x4f17db] 9: (MDSRank::retry_dispatch(Message*)+0x12) [0x4f1ec2] 10: (MDSInternalContextBase::complete(int)+0x67) [0x74faf7] 11: (MDSRank::_advance_queues()+0xf1) [0x4f0781] 12: (MDSRank::ProgressThread::entry()+0x43) [0x4f0e03] 13: (()+0x76ba) [0x7fa71f0216ba] 14: (clone()+0x6d) [0x7fa71e84a41d] -401> 2019-09-11 13:43:25.844 7fa719aeb700 1 -- 10.10.30.115:6800/1442163404 <== osd.49 10.10.30.56:6838/15753 3 ==== osd_op_reply(90 600.00000000 [omap-get-header,omap-get-vals,getxattr (62)] v0'0 uv98420 ondisk = 0) v8 ==== 240+0+437012 (2786733188 0 4243776564) 0x8b5e080 con 0x3addc00 -401> 2019-09-11 13:43:25.848 7fa71292e700 -1 *** Caught signal (Aborted) ** in thread 7fa71292e700 thread_name:mds_rank_progr ceph version 13.2.6 (7b695f835b03642f85998b2ae7b6dd093d9fbce4) mimic (stable) 1: (()+0x11390) [0x7fa71f02b390] 2: (gsignal()+0x38) [0x7fa71e778428] 3: (abort()+0x16a) [0x7fa71e77a02a] 4: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x256) [0x7fa71f7a5a86] 5: (()+0x2fab07) [0x7fa71f7a5b07] 6: (Server::_unlink_local(boost::intrusive_ptr<MDRequestImpl>&, CDentry*, CDentry*)+0x15e8) [0x548fa8] 7: (Server::handle_client_unlink(boost::intrusive_ptr<MDRequestImpl>&)+0x961) [0x549991] 8: (Server::handle_client_request(MClientRequest*)+0x49b) [0x563beb] 9: (Server::dispatch(Message*)+0x2fb) [0x5678cb] 10: (MDSRank::handle_deferrable_message(Message*)+0x434) [0x4da3c4] 11: (MDSRank::_dispatch(Message*, bool)+0x89b) [0x4f17db] 12: (MDSRank::retry_dispatch(Message*)+0x12) [0x4f1ec2] 13: (MDSInternalContextBase::complete(int)+0x67) [0x74faf7] 14: (MDSRank::_advance_queues()+0xf1) [0x4f0781] 15: (MDSRank::ProgressThread::entry()+0x43) [0x4f0e03] 16: (()+0x76ba) [0x7fa71f0216ba] 17: (clone()+0x6d) [0x7fa71e84a41d] NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.

4 years, 8 months

1
0
0 0

bluestore fsck behavior with legacy stats etc

by Sage Weil

Background: In nautilus, bluestore started maintaining usage stats on a per-pool basis. BlueStore OSDs created before nautilus lack these stats. Running a ceph-bluestore-tool repair can calculate the usage so that the OSD can maintain and report them going forward. There are two options: - bluestore_warn_on_legacy_statfs (bool, default: true), which makes the cluster issue a health warning when there are OSDs that have legacy stats. - bluestore_no_per_pool_stats_tolerance (enum enforce, until_fsck, until_repair, default: until_repair). 'until_fsck' will tolerate the legacy but fsck will fail 'until_repair' will tolerate the legacy but fsck will pass 'enforce' will tolerate the legacy but disable the warning The octopus addition of per-pool omap usage tracking presents an identical problem: a new tracking ability in bluestore that reqires a conversion to enable after upgrade. I think that we can simplify these settings and make them less confusing, still with two options: - bluestore_fsck_error_on_no_per_pool_omap (bool, default: false). During fsck, we can either generate a 'warning' about non-per-pool omap, or an error. Generate a warning by default, which means that the fsck return code can indicate success. - bluestore_warn_on_no_per_pool_omap (bool, default: true). At runtime, we can generate a health warning if the OSD is using the legacy non-per-pool omap. The overall default behavior is the same as we have with the legacy_statfs: OSDs still work, fsck passes, and we generate a health warning. Setting bluestore_warn_on_no_per_pool_omap=false is the same, AFAICS, as setting bluestore_no_per_pool_stats_tolerance=enforce. (Except maybe repair won't do the conversion? I don't see why we'd ever not want to do the conversion, though.) Setting bluestore_fsck_error_on_no_per_pool_omap=true is the same, AFAICS, as bluestore_no_per_pool_stats_tolerance=until_fsck. Overall, this seems simpler and easier for a user to understand. Realistically, the only option I expect a user will ever change is bluestore_warn_on_no_per_pool_omap=false to make the health warning go away after an upgrade. What do you think? Should I convert the legacy_statfs to behave the same way? sage

4 years, 8 months

3
2
0 0

DocuBetter EMEA - CephFS

by Neha Ojha

Hi Folks, The next DocuBetter meeting is scheduled for tomorrow, September 11 at 9.30 am PT. Etherpad: https://pad.ceph.com/p/Ceph_Documentation Meeting: https://bluejeans.com/908675367 Agenda: This week we will be discussing documentation gaps in CephFS and talk about efforts that have been started to bridge those gaps. Hope to see you there! Here's the recording from the last meeting where we discussed RADOS documentation gaps: https://youtu.be/FRNXAqk9IfQ Thanks, Neha

4 years, 8 months

1
0
0 0

***** lists.ceph.io SPAM 7.9 ***** Re: Electronic Components supplier（Good quality & Low price & Sample free）

by Robin

4 years, 8 months

1
0
0 0

2024

2023

2022

2021

2020

2019

Dev September 2019