Duy Nguyen writes:
> Another aspect that's not mentioned is, we keep this daemon's logic as
> thin as possible. The "brain" stays in git. So the daemon can read and
> validate stuff, but that's about all it's allowed to do. It's not
> supposed to add/create new contents. It's not even allowed to
On Thu, Mar 10, 2016 at 6:09 AM, Junio C Hamano wrote:
> David Turner writes:
>
>> From: Nguyễn Thái Ngọc Duy
>>
>> Instead of reading the index from disk and worrying about disk
>> corruption, the index is cached in memory (memory bit-flips happen
>> too, but hopefully less often). The result i
On Thu, Mar 10, 2016 at 1:36 AM, David Turner wrote:
> Git can poke the daemon to tell it to refresh the index cache, or to
> keep it alive some more minutes via UNIX signals.
The reason I went with UNIX signals was because it made it possible to
make a simple GetMessage loop, the only thing I ca
On Fri, Mar 11, 2016 at 3:22 AM, David Turner wrote:
> Reads (ignoring SHA verification) will be slightly slower (due to the
> btree overhead). If, in general, we only had to read part of the
> index, that would be faster. But a fair amount of git code is written
> to assume that it is reasonable
On Thu, 2016-03-10 at 18:17 +0700, Duy Nguyen wrote:
> On Thu, Mar 10, 2016 at 6:21 AM, Junio C Hamano
> wrote:
> > Junio C Hamano writes:
> >
> > > David Turner writes:
> > >
> > > > From: Nguyễn Thái Ngọc Duy
> > > >
> > > > Instead of reading the index from disk and worrying about disk
>
On Thu, Mar 10, 2016 at 6:21 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> David Turner writes:
>>
>>> From: Nguyễn Thái Ngọc Duy
>>>
>>> Instead of reading the index from disk and worrying about disk
>>> corruption, the index is cached in memory (memory bit-flips happen
>>> too, but
On Wed, 2016-03-09 at 15:09 -0800, Junio C Hamano wrote:
> David Turner writes:
>
> > From: Nguyễn Thái Ngọc Duy
> >
> > Instead of reading the index from disk and worrying about disk
> > corruption, the index is cached in memory (memory bit-flips happen
> > too, but hopefully less often). The
On Wed, 2016-03-09 at 15:21 -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > David Turner writes:
> >
> > > From: Nguyễn Thái Ngọc Duy
> > >
> > > Instead of reading the index from disk and worrying about disk
> > > corruption, the index is cached in memory (memory bit-flips
> > >
Junio C Hamano writes:
> David Turner writes:
>
>> From: Nguyễn Thái Ngọc Duy
>>
>> Instead of reading the index from disk and worrying about disk
>> corruption, the index is cached in memory (memory bit-flips happen
>> too, but hopefully less often). The result is faster read. Read time
>> is
David Turner writes:
> From: Nguyễn Thái Ngọc Duy
>
> Instead of reading the index from disk and worrying about disk
> corruption, the index is cached in memory (memory bit-flips happen
> too, but hopefully less often). The result is faster read. Read time
> is reduced by 70%.
>
> The biggest ga
From: Nguyễn Thái Ngọc Duy
Instead of reading the index from disk and worrying about disk
corruption, the index is cached in memory (memory bit-flips happen
too, but hopefully less often). The result is faster read. Read time
is reduced by 70%.
The biggest gain is not having to verify the traili
11 matches
Mail list logo
