The default -- size tiered.
https://issues.apache.org/jira/browse/CASSANDRA-12979 mentioned checkAvailableDiskSpace -- does this function compute a total that includes all volumes on the system, rather than just the ones available to Cassandra? There is also a system volume has 2.3 T, so if it is adding all free space on the system, then it could possibly reach a number that size. But, it should make sure that there is a single volume with that amount of free space, otherwise it is still impossible to complete the compaction. On Fri, Oct 13, 2017 at 5:40 PM, Dikang Gu <dikan...@gmail.com> wrote: > What's the compaction strategy are you using? level compaction or size > tiered compaction? > > On Fri, Oct 13, 2017 at 4:31 PM, Bruce Tietjen < > bruce.tiet...@imatsolutions.com> wrote: > >> I hadn't noticed that is is now attempting two impossible compactions: >> >> >> id compaction type keyspace table >> completed total unit progress >> a7d1b130-b04c-11e7-bfc8-79870a3c4039 Compaction perfectsearch cxml >> 1.73 TiB 5.04 TiB bytes 34.36% >> b7b98890-b063-11e7-bfc8-79870a3c4039 Compaction perfectsearch cxml >> 867.4 GiB 6.83 TiB bytes 12.40% >> Active compaction remaining time : n/a >> >> >> On Fri, Oct 13, 2017 at 5:27 PM, Jon Haddad <j...@jonhaddad.com> wrote: >> >>> Can you paste the output of cassandra compactionstats? >>> >>> What you’re describing should not happen. There’s a check that drops >>> sstables out of a compaction task if there isn’t enough available disk >>> space, see https://issues.apache.org/jira/browse/CASSANDRA-12979 for >>> some details. >>> >>> >>> On Oct 13, 2017, at 4:24 PM, Bruce Tietjen < >>> bruce.tiet...@imatsolutions.com> wrote: >>> >>> >>> We are new to Cassandra and have built a test cluster and loaded some >>> data into the cluster. >>> >>> We are seeing compaction behavior that seems to violate what we read >>> about it's behavior. >>> >>> Our cluster is configured with JBOD with 3 3.6T disks. Those disks >>> currently respectively have the following used/available space: >>> Disk Used Available >>> sdb1 1.8T 1.7T >>> sdc1 1.8T 1.6T >>> sdd1 1.5T 2.0T >>> >>> nodetool compactionstats -H reports that the compaction system is >>> attempting to do a compaction that has a total of 6.83T >>> >>> The system hasn't had that much free space since sometime after we >>> started loading data and there has never been that much free space on a >>> single disk, so why would it ever attempt such a compaction? >>> >>> What have we done wrong, or am I reading this wrong? >>> >>> We have seen the same behavior on most of our 8 nodes. >>> >>> Can anyone tell us what is happening or what we have done wrong? >>> >>> Thanks >>> >>> >>> >> > > > -- > Dikang > >
