You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Mark Malamut (JIRA)" <ji...@apache.org> on 2014/04/24 02:28:14 UTC
[jira] [Updated] (CASSANDRA-7080) Enhance robustness of snapshot
deletions
[ https://issues.apache.org/jira/browse/CASSANDRA-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Malamut updated CASSANDRA-7080:
------------------------------------
Description:
While investigating snapshot deletion on Windows, I encountered the condition where snapshots would not delete. After testing on Server 2008 and 2012, I found that running nodetool clearsnapshot would remove some of the snapshot files (3 of 35 in my test case), yet the OS could delete many more (an additional 27). Nodetool clearsnapshot terminates as soon as it encounters *any* snapshot file that it cannot delete.
It should be noted that it appears nodetool clearsnapshot works *after* the data files are deleted by a subsequent compaction although I have not proved this definitively.
I read that improvements are planned for C* 3.0 in this area. It would seem to make sense to make nodetool clearsnapshot more robust regardless of related fixes. A simple solution would be to allow FileUtils:deleteRecursive to catch and continue deleting or logging this condition without the throw from FileUtils:deleteWithConfirm.
If a file is locked for some reason (even under Linux), this could cause a significant amount of disk space to be needlessly occupied.
> Enhance robustness of snapshot deletions
> ----------------------------------------
>
> Key: CASSANDRA-7080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7080
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Mark Malamut
> Priority: Trivial
> Fix For: 2.0.8
>
>
> While investigating snapshot deletion on Windows, I encountered the condition where snapshots would not delete. After testing on Server 2008 and 2012, I found that running nodetool clearsnapshot would remove some of the snapshot files (3 of 35 in my test case), yet the OS could delete many more (an additional 27). Nodetool clearsnapshot terminates as soon as it encounters *any* snapshot file that it cannot delete.
> It should be noted that it appears nodetool clearsnapshot works *after* the data files are deleted by a subsequent compaction although I have not proved this definitively.
> I read that improvements are planned for C* 3.0 in this area. It would seem to make sense to make nodetool clearsnapshot more robust regardless of related fixes. A simple solution would be to allow FileUtils:deleteRecursive to catch and continue deleting or logging this condition without the throw from FileUtils:deleteWithConfirm.
> If a file is locked for some reason (even under Linux), this could cause a significant amount of disk space to be needlessly occupied.
--
This message was sent by Atlassian JIRA
(v6.2#6252)