[
https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012517#comment-13012517
]
Jonathan Ellis commented on CASSANDRA-1902:
-------------------------------------------
Okay, so we *are* adding a copy by using getByteArray. I guess that takes care
of the race conditions but it baffles me that copy + wrap can be as fast as
duplicate + set position. (duplicate != copy.)
All the order(nativeOrder) call does is set byte order for things like the get*
methods, which all look like this:
{code}
private long getLong(long a) {
if (unaligned) {
long x = unsafe.getLong(a);
return (nativeByteOrder ? x : Bits.swap(x));
}
return Bits.getLong(a, bigEndian);
}
{code}
And here is where unaligned gets set:
{code}
static boolean unaligned() {
if (unalignedKnown)
return unaligned;
PrivilegedAction pa
= new sun.security.action.GetPropertyAction("os.arch");
String arch = (String)AccessController.doPrivileged(pa);
unaligned = arch.equals("i386") || arch.equals("x86") ||
arch.equals("x86_64")
|| arch.equals("amd64") || arch.equals("ppc"); // Mac OS X / PPC:
see Radar #3253257
unalignedKnown = true;
return unaligned;
}
{code}
... so byte ordering is basically a no-op on any architecture we are likely to
run on.
> Migrate cached pages during compaction
> ---------------------------------------
>
> Key: CASSANDRA-1902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1902
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.1
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Fix For: 0.7.5, 0.8
>
> Attachments:
> 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt,
> 1902-formatted.txt, 1902-per-column-migration-rebase2.txt,
> 1902-per-column-migration.txt, CASSANDRA-1902-v3.patch,
> CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch
>
> Original Estimate: 32h
> Time Spent: 56h
> Remaining Estimate: 0h
>
> Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a
> pre-compacted CF during the compaction process. This is now important since
> CASSANDRA-1470 caches effectively nothing.
> For example an active CF being compacted hurts reads since nothing is cached
> in the new SSTable.
> The purpose of this ticket then is to make sure SOME data is cached from
> active CFs. This can be done my monitoring which Old SSTables are in the page
> cache and caching active rows in the New SStable.
> A simpler yet similar approach is described here:
> http://insights.oetiker.ch/linux/fadvise/
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
