On Mon, Nov 21, 2011 at 11:26 AM, sridhar basam wrote:
>
>
> On Mon, Nov 21, 2011 at 10:34 AM, Edward Capriolo
> wrote:
>
>>
>>
>> On Mon, Nov 21, 2011 at 10:07 AM, Dan Hendry
>> wrote:
>>
>>> Pretty sure your argument about indirect blocks making large files
>>> inefficient only pertains to ex
On Mon, Nov 21, 2011 at 10:34 AM, Edward Capriolo wrote:
>
>
> On Mon, Nov 21, 2011 at 10:07 AM, Dan Hendry wrote:
>
>> Pretty sure your argument about indirect blocks making large files
>> inefficient only pertains to ext2/3 and not ext4. It seems ext4 replaces
>> the
>> 'indirect block' approach
e tiered compaction.
>
> Dan
>
> -Original Message-
> From: Radim Kolar [mailto:h...@sendmail.cz]
> Sent: November-19-11 19:42
> To: user@cassandra.apache.org
> Subject: Re: split large sstable
>
> Dne 17.11.2011 17:42, Dan Hendry napsal(a):
> > What
gt; compelling reason ext4 should be chosen (over ext3) for Cassandra - at
> least
> when using size tiered compaction.
>
An alternative is XFS, which is also extent based.
>
> Dan
>
> -Original Message-
> From: Radim Kolar [mailto:h...@sendmail.cz]
> Sent: Nov
mber-19-11 19:42
To: user@cassandra.apache.org
Subject: Re: split large sstable
Dne 17.11.2011 17:42, Dan Hendry napsal(a):
> What do you mean by ' better file offset caching'? Presumably you mean
> 'better page cache hit rate'?
fs metadata used to find blocks in smaller f
Dne 17.11.2011 17:42, Dan Hendry napsal(a):
What do you mean by ' better file offset caching'? Presumably you mean
'better page cache hit rate'?
fs metadata used to find blocks in smaller files are cached better.
Large files are using indirect blocks and you need more reads to find
correct bloc
What do you mean by ' better file offset caching'? Presumably you mean
'better page cache hit rate'? Out of curiosity, why do you think this? What
data are you seeing which makes you think it's better? I am certainly not
even close to a virtual memory or page caching expert but I am pretty sure
fil
