I have updated OAK-2082 with test run results. Looking at the result I
think FDS does provide a benefit in terms of lesser storage space.
Putting Lucene index on file system provides best storage efficiency
but then it would not work once we have TarMK failover implemented.
Chetan Mehrotra
On Tu
Hi,
In addition or instead of using the BlobStore, we could store the Lucene
index to the filesystem (persistence = file, path = ...).
But I would probably only do that on a case-by-case basis. I think it
would reduce, but not solve the compaction problem. Some numbers from a
test repository I ha
On Fri, Sep 5, 2014 at 3:26 PM, Michael Dürig wrote:
> I'd leave the default as it is for Oak as this has the beauty of simplicity.
> We could just change it for applications where we know that the inline
> storing of binaries is troublesome.
Ack. Yes default setup should not be modified
> OTOH
On 4.9.14 1:25 , Chetan Mehrotra wrote:
Given that such repository growth is troublesome it might be better if
we configure a BlobStore by default with SegmentNodeStore (or atleast
for applications like AEM). This should reduce the rate of repository
growth due to
I'd leave the default as it
On 04/09/2014 12:25, Chetan Mehrotra wrote:
> ... (supermegacut!)
>
> Thoughts?
>
As you mentioned AEM, the deployment based on JR2 already delivers 2
different directories for repository/segment and blobs.
Both AEM and JR2 are used to run separate tasks for cleaning the blobs IIRC.
So I'm in fav
Hi Team,
Currently SegmentNodeStore does not uses BlobStore by default and
stores the binary data within data tar files. This has the goodness
that
1. Backup is simpler - User just needs to backup segmentstore directory
2. No Blob GC - The RevisionGC would also delete the binary content and a
