>> In any case: Monitoring disk-space is very very important.
>
> So, why doesn't cassandra monitor it itself and stop accepting writes if it
> runs out of space?
For one thing, it's non-trivial to do accurately because disk space
usage varies over time due to background compaction and/or
anti-co
On Dec 22, 2010, at 16:20, Peter Schuller wrote:
> In any case: Monitoring disk-space is very very important.
So, why doesn't cassandra monitor it itself and stop accepting writes if it
runs out of space?
p, it goes out
> > of disk just from the commit log replay of only 6 gig? Sounds like
> > you're very, very full.
>
> Answer:
>
> $ time cassandra -f
> INFO 16:30:09,486 Heap size: 2143158272/2143158272
> log4j:ERROR Failed to flush writer,
> java.io.IOException: No spa
m the commit log replay of only 6 gig? Sounds like
> you're very, very full.
Answer:
$ time cassandra -f
INFO 16:30:09,486 Heap size: 2143158272/2143158272
log4j:ERROR Failed to flush writer,
java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Nat
> And the data could be more evenly balanced, obviously. However the nodes
> fails to startup because due of lacking disk space (instead of starting up
> and denies further writes it appears to try to process the [6.6G!] commit
> logs). So, I cannot perform any actions on it no more like re-bala
So, this is my ring, the third node ran out of disk space:
Address Status State LoadOwnsToken
139315361777093290765734121398073449298
192.168.68.76 Up Normal 37.83
