[ 
https://issues.apache.org/jira/browse/CASSANDRA-12498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427610#comment-15427610
 ] 

Jeff Jirsa commented on CASSANDRA-12498:
----------------------------------------

Sort of -0 on this for two reasons: 

{code}
For JBOD configuration where you have multiple data directories, keeping the 
one level before ksName/cfName-UUID should be adequat
{code}

In the jbod/multiple data dir case, you may have lots of prefixes with similar 
names, ie: {{/mnt1/cassandra/data/ks/tbl}}, {{/mnt2/cassandra/data/ks/tbl}}, 
and so on. It's impossible to predict how users will name/organize their jbod 
system, so you'd be trying to guess, and inevitably cause pain for someone.

Also, I suspect that the repetitive log entries are annoying, but they also 
allow operators to do some intelligent scripting via log parsing that would be 
complicated if the prefixes disappear.

> Shorten the sstable log message as it unnecessarily contains the full path of 
> a SSTable
> ---------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-12498
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12498
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Observability
>            Reporter: Wei Deng
>            Priority: Minor
>
> There are a lot of places in debug.log where we print out the name of a 
> SSTable. This is useful to look at the full path of a SSTable file when 
> you're investigating individual SSTable. However, during compaction, we often 
> see 32 SSTables getting compacted at the same time, and the corresponding log 
> line becomes very repetitive and hard to read as most of them are repeating 
> the same first part of the file system path again and again, like the 
> following:
> {noformat}
> DEBUG [CompactionExecutor:94] 2016-08-18 06:33:17,185  
> CompactionTask.java:146 - Compacting (a5ca2f10-650d-11e6-95ef-a561ab3c45e8) 
> [/var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-200-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-201-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-16-big-Data.db:level=0,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-204-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-205-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-203-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-202-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-207-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-206-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-3-big-Data.db:level=0,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-208-big-Data.db:level=1,
>  
> /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-209-big-Data.db:level=1,
>  ]
> {noformat}
> We should remove any text one level before ksName/cfName-UUID/ as it's very 
> easy to get them from cassandra.yaml. For JBOD configuration where you have 
> multiple data directories, keeping the one level before ksName/cfName-UUID 
> should be adequate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to