[
https://issues.apache.org/jira/browse/CASSANDRA-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602673#comment-15602673
]
Bhaskar Muppana commented on CASSANDRA-6719:
--------------------------------------------
Thanks for the fix [~MarkReddy]. This is quite useful. I have couple of
comments on patch.
* In your patch I see you are using {{getWriteableLocationAsFile()}} to get the
data directory to move the SSTable into. Here, we can reduce the disk overhead,
by taking advantage of the possibility that external SSTable directory provided
by user could be on the same disk partition as one of the Cassandra data
directories, if so we can just use that as data directory. As same partition
move would be simple inode operations. Between partitions that will involve lot
of unnecessary data copy taking extra disk ops having effect on read/write
latencies. I am suggesting using a function like below instead
{code:java|borderStyle=solid}
public File getWriteableLocationForLoadingAsFile(final File sourceFile)
throws IOException
{
final FileStore srcFileStore = Files.getFileStore(sourceFile.toPath());
for (final DataDirectory dataDir : paths)
{
if
(BlacklistedDirectories.isUnwritable(getLocationForDisk(dataDir)))
{
logger.trace("removing blacklisted candidate {}",
dataDir.location);
continue;
}
final File dataPath = getLocationForDisk(dataDir);
if (Files.getFileStore(dataPath.toPath()).equals(srcFileStore))
{
return dataPath;
}
}
return getWriteableLocationAsFile(sourceFile.length());
}
{code}
* Does it make sense to provide an option weather to move or just copy SSTables
to user? So, user will have SSTables even after completing {{nodetool
refresh}}. I agree, default has to be moving SSTables.
* Shall we make SSTableLister a static class not depending on Directories
object. So, the definition would be less ambiguous as the constructor either
means it is working on dataDirectories or just on external directory but linked
to directories object in both cases.
{code:java|borderStyle=solid}
public static class SSTableLister
{
public SSTableLister(List<File> directory, OnTxnErr onTxnErr, String
keyspace, String table)
{
....
}
}
{code}
> redesign loadnewsstables
> ------------------------
>
> Key: CASSANDRA-6719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6719
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
> Reporter: Jonathan Ellis
> Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 6719.patch
>
>
> CFSMBean.loadNewSSTables scans data directories for new sstables dropped
> there by an external agent. This is dangerous because of possible filename
> conflicts with existing or newly generated sstables.
> Instead, we should support leaving the new sstables in a separate directory
> (specified by a parameter, or configured as a new location in yaml) and take
> care of renaming as necessary automagically.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
