Great, thanks a lot for the help, guys. I just did the truncation + clearsnapshot just now - worked smoothly.. :) Freed up 400GB, yay \o/
Really appreciate your help. Thanks once again. Kunal On 21 April 2017 at 15:04, Nicolas Guyomar <nicolas.guyo...@gmail.com> wrote: > Hi Kunal, > > Timeout usually occured in the client (eg cqlsh), it does not mean that > the truncate operation is interrupted. > > Have you checked that you have no old snapshot (automatic snaphost for > instance) that you could get rid off to get some space back ? > > On 21 April 2017 at 11:27, benjamin roth <brs...@gmail.com> wrote: > >> Truncate needs no space. It just creates a hard link of all affected >> SSTables under the corresponding -SNAPSHOT dir (at least with default >> settings) and then removes the SSTables. >> Also this operation should be rather fast as it is mostly a file-deletion >> process with some metadata updates. >> >> 2017-04-21 11:21 GMT+02:00 Kunal Gangakhedkar <kgangakhed...@gmail.com>: >> >>> Hi all, >>> >>> We have a CF that's grown too large - it's not getting actively used in >>> the app right now. >>> The on-disk size of the <ks>.<cf> directory is ~407GB and I have only >>> ~40GB free left on the disk. >>> >>> I understand that if I trigger a TRUNCATE on this CF, cassandra will try >>> to take snapshot. >>> My question: >>> Is the ~40GB enough to safely truncate this table? >>> >>> I will manually remove the <ks>.<cf> directory once the truncate is >>> completed. >>> >>> Also, while browsing through earlier msgs regarding truncate, I noticed >>> that it's possible to get OperationTimedOut >>> <http://www.mail-archive.com/user@cassandra.apache.org/msg48958.html> >>> exception. Does that stop the truncate operation? >>> >>> Is there any other safe way to clean up the CF? >>> >>> Thanks, >>> Kunal >>> >> >> >
