Re: [RFC/PATCH v4 00/49] Add initial experimental external ODB support

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 3, 2017, 16:56 UTC
Message-ID: <xmqqlgo5mpc1.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAP8UFD3YPXRDc8ThSuTWjKDQ2i+zqNrhBi6JfEuTPXnNA6LUiw@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 19 quoted lines

> On Sat, Jul 1, 2017 at 10:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>>>> I think it would be good to ensure the
>>>> interface is robust and performant enough to actually replace the current
>>>> object store interface (even if we don't actually do that just yet).
>>>
>>> I agree that it should be robust and performant, but I don't think it
>>> needs to be as performant in all cases as the current object store
>>> right now.
>>
>> That sounds like starting from a defeatest position.  Is there a
>> reason why you think using an external interface could never perform
>> well enough to be usable in everyday work?
>
> Perhaps in the future we will be able to make it as performant as, or
> perhaps even more performant, than the current object store, but in
> the current implementation the following issues mean that it will be
> less performant

That might be an answer to a different question; I was hoping to hear that it should be performant enough for everyday work, but never thought it would perform as well as local disk.

I haven't used network filesystem quite a while, but a repository on NFS may still usable, and we know our own access pattern bettern than NFS which cannot anticipate what paths the next operations by its client happen, so it is not inconceivable that a well designed external object database interface would let us outperform "repo on NFS" scenario.