RE: Git 2.54.0-rc1, subtests of t5310, t5326, t5327

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Apr 8, 2026, 22:04 UTC
Message-ID: <016e01dcc7a3$9f0d06e0$dd2714a0$@nexbridge.com>
In-Reply-To: <xmqqcy09xh53.fsf@gitster.g>

On April 8, 2026 5:43 PM, Junio C Hamano wrote:

Show 32 quoted lines

><rsbecker@nexbridge.com> writes:
>
>> On April 8, 2026 4:22 PM, Junio C Hamano wrote:
>>><rsbecker@nexbridge.com> writes:
>>>
>>>> On my box, I have the following note:
>>>>
>>>> Specifying  the sum of the iov_len values in the iov array greater
>>>> than the OSS I/O size limit for that open causes the  writev()
>>>> function  to return  -1  and  set errno to [EINVAL].
>>>
>>>That is unexpected.
>>>
>>>writev() may fail if the sum of iov_len would not fit within ssize_t
>>>with
>> EINVAL, but
>>>unless your "the OSS I/O size limit" is the same as SSIZE_MAX, what
>>>you
>> have above
>>>is not quite the same.
>>>
>>>Does your build work with NO_WRITEV=Nope?  I think I saw it asked a
>>>few
>> times
>>>but I do not recall seeing it answered.  At least we know
>>>xwrite() seems to work well enough on your system, which is what the
>>>writev() emulation is written in terms of, so I suspect it would.
>>
>> Yes, NO_WRITEV=Nope does compile and execute. I am including it in our
>> CI/CD job for now. Can we plan on a fix for this?
>
>What I have heard so far indicate that the code that uses writev() would

need to

>loop over to prepare for short writes, but your
>writev() that fails for "the OSS I/O size limit" (whatever it is) does not

sound like

>something we want to change the callers to chomp the writev() calls into

smaller

>chunks for.  Such a platform is far better off using the compat/writev for

the code

>path we recently started using writev() in.
>
>To be quite honest, I am not sure if it is even worth using writev() if we

need a loop

>that protects against shrot writes, so unless I am grossly mistaken (e.g.,

perhaps

>there is some guarantee that there won't be any short writes for writev()

that sends

>data smaller than 64k that I missed in the docs), the best course of action

might be

>to revert the change to use writev() and use the two write(2)s as before,

*if* we

>actually observe that the current code is broken by short writes.

I am 100% sure that EINVAL is returned by writev() on NonStop if the size exceeds 52K In 32-bit models. Whether it supports 868K for 64-bit is conjecture. NO_WRITEV=Nope works, which I am trying for everything at RC1, then we can live with this.