I want to point out something:
https://issues.apache.org/jira/browse/CASSANDRA-6846
"I'm definitively -1 on putting any type of contract on the internals. They
are called internals for a reason, and if rewriting it all entirely
tomorrow is best for Cassandra, we should have the possibility to do
Benedict mentioned it briefly above, but the earliest / most detailed
conversation on this can be found in CASSANDRA-1470.
You may also find some stuff from the dev list and other issues around
the same time from specifically from Chris G. and Peter S. (names on
that ticket) as, IIRC, they were bo
I'm not certain this is the best way to go about encouraging people to help
you, or generally encourage participation in the project. You have seemed
to lash out at the project (and in this case me specifically) in a fairly
antagonistic manner a multitude of times in just a couple of hours.
Your
Sorry, No. Always document your assumptions. I shouldn't need to git blame a
thousand commits and read thru a billion tickets to maybe understand why
something was done. Clearly thru the conversations on this topic I've had on
IRC and the responses so far on this email thread it's not/still not
; The main point is to avoid keeping things in the page cache that are no
> longer needed like compacted data that has been early opened elsewhere.
>
> On Oct 18, 2016 11:29 AM, "Michael Kjellman" <mailto:mkjell...@internalcircle.com>
> <mailto:mkjell...@internalcircl
sandra
fashion no comments were provided.
There is a check the OS is Linux (okay, a start) but it turns out the
behavior of providing a length of 0 to posix_fadvise changed in some 2.6
kernels. We don't check the kernel version -- or even note it.
What is the *expected* outcome of our use of posix_fa
nd in stereotypical Cassandra
> fashion no comments were provided.
>
> There is a check the OS is Linux (okay, a start) but it turns out the
> behavior of providing a length of 0 to posix_fadvise changed in some 2.6
> kernels. We don't check the kernel version -- or even note it.
>
&
Hi,
Compaction can merge some very large files together with data that may
be completely cold. So yeah caching the whole file just creates pressure
to evict useful stuff. In some theories.
In other theories the page cache is flush and scan resistant and should
just eat this stuff up without inter
Within a single SegmentedFile?
On Oct 18, 2016, at 9:02 AM, Ariel Weisberg
mailto:ariel.weisb...@datastax.com>> wrote:
With compaction there can be hot and cold data mixed together.
;> fashion no comments were provided.
> >>
> >> There is a check the OS is Linux (okay, a start) but it turns out the
> >> behavior of providing a length of 0 to posix_fadvise changed in some 2.6
> >> kernels. We don't check the kernel version -- or even note
no comments were provided.
There is a check the OS is Linux (okay, a start) but it turns out the
behavior of providing a length of 0 to posix_fadvise changed in some 2.6
kernels. We don't check the kernel version -- or even note it.
What is the *expected* outcome of our use of posix_fadvise --
out the
>> behavior of providing a length of 0 to posix_fadvise changed in some 2.6
>> kernels. We don't check the kernel version -- or even note it.
>>
>> What is the *expected* outcome of our use of posix_fadvise -- not what
>> does it do or not do today --
hion no comments were provided.
>
> There is a check the OS is Linux (okay, a start) but it turns out the
> behavior of providing a length of 0 to posix_fadvise changed in some 2.6
> kernels. We don't check the kernel version -- or even note it.
>
> What is the *expected* out
posix_fadvise changed in some 2.6
kernels. We don't check the kernel version -- or even note it.
What is the *expected* outcome of our use of posix_fadvise -- not what
does it do or not do today -- but what problem was it added to solve and
what's the expected behavior regardless of ke
; There is a check the OS is Linux (okay, a start) but it turns out the
> behavior of providing a length of 0 to posix_fadvise changed in some 2.6
> kernels. We don't check the kernel version -- or even note it.
>
> What is the *expected* outcome of our use of posix_fadvise -- no
rsion -- or even note it.
What is the *expected* outcome of our use of posix_fadvise -- not what does it
do or not do today -- but what problem was it added to solve and what's the
expected behavior regardless of kernel versions.
best,
kjellman
Sent from my iPhone
16 matches
Mail list logo
