OK, I would like to do it. Thanks for comments. 2017-01-12 21:41 GMT+08:00 Sage Weil <sage@xxxxxxxxxxxx>: > On Thu, 12 Jan 2017, John Spray wrote: >> On Thu, Jan 12, 2017 at 8:12 AM, liuchang0812 <liuchang0812@xxxxxxxxx> wrote: >> > Hi, all >> > >> > In our documentation, it says that: >> > >> > Ceph’s logging levels operate on a scale of 1 to 20, where 1 >> > is terse and 20 is verbose. >> > >> > http://docs.ceph.com/docs/master/rados/troubleshooting/log-and-debug/#subsystem-log-and-debug-settings >> > >> > >> > But, it seems that there are some logging levels 25 : >> > >> > >> > mds/MDBalancer.cc:276: dout(25) << "=== got heartbeat " << >> > m->get_beat() << " from " << m->get_source().num() << " " << >> > m->get_load() << dendl; >> > mds/CInode.cc:4189: dout(25) << __func__ << dendl; >> > mds/MDCache.cc:11656: //dout(25) << "saw depth " << d << " " << >> > *dir << dendl; >> > mds/MDCache.cc:11666: //dout(25) << " saw sub " << **p << dendl; >> > mds/journal.cc:373: dout(25) << "EMetaBlob::add_dir_context(" << >> > dir << ") maybe " << >> > >> > >> > So, shoud we update our documentation, or update logging level to 20? >> >> Probably neither -- the >20 log messages are intentionally obscure >> things (although I do accept that there is a reasonable argument that >> if we would never turn something on in a real system then we perhaps >> should not have it in the code...) > > FWIW, the guideline I tend to use: > > 10 - O(requests) > 20 - O(requests) or O(internal structures). e.g., we dump pg log entries > and dump every element other ptoential large data structures at 20 > 30 - O(bytes). several bits of code hexdump actual read/write data at > 30) > > You could update the doc to mention that there are levels >20 in some rare > cases and that they are extremely verbose. > > sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
