Re: [PATCH 0/3] Another approach to large transactions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 17, 2015 at 4:31 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
>> On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>>
>>> This is now pushed out and sitting at the tip of 'pu'.  It seems to
>>> break one of the tests in 1400 when merged to 'next', but I didn't
>>> look it closely.
>>>
>>> Thanks.
>>
>> ok, I'll look more closely.
>
> Apparently I screwed up even before sending the patches over the wire.

For the deleting refs test failing:
The problem comes from guessing the number of fds we're allowed to use.
At first I thought it was a fundamental issue with the code being broken, but
it turns out we just need a larger offset as we apparently have 9 files open
already, before the transaction even starts.
I did not expect the number to be that high, which is why I came up with the
arbitrary number of 8 (3 for stdin/out/err, maybe packed refs and reflog so I
guessed, 8 would do fine).

I am not sure if the 9 is a constant or if it scales to some unknown
property yet.
So to make the series work, all we need is:

- int remaining_fds = get_max_fd_limit() - 8;
+ int remaining_fds = get_max_fd_limit() - 9;

I am going to try to understand where the 9 comes from and resend the patches.

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]