Linus Torvalds writes:
> So it would probably be a great idea to make the filtering code able
> to do things in smaller chunks, but I suspect that the patch to chunk
> up xread/xwrite is the right thing to do anyway.
Yes and yes, but the first yes is a bit tricky for writing things
out, as the r
On Mon, Aug 19, 2013 at 2:56 PM, Kyle J. McKay wrote:
>
> The fact that the entire file is read into memory when applying the filter
> does not seem like a good thing (see #7-#10 above).
Yeah, that's horrible. Its likely bad for performance too, because
even if you have enough memory, it blows ev
On Aug 19, 2013, at 10:16, Junio C Hamano wrote:
Linus Torvalds writes:
So why isn't the patch much more straightforward? Like the attached
totally untested one that just limits the read/write size to 8MB
(which is totally arbitrary, but small enough to not have any latency
issues even on slo
On Mon, Aug 19, 2013 at 10:16 AM, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> The same argument applies to xwrite(), but currently we explicitly
> catch EINTR and EAGAIN knowing that on sane systems these are the
> signs that we got interrupted.
>
> Do we catch EINVAL unconditionally in th
Steffen Prohaska writes:
> I'm happy to rework it again towards your suggestion. I would also remove
> the compat wrapper for write(). But I got a bit tired. I'd appreciate if
> I received more indication whether a version without compat wrappers would
> be accepted.
I think it is a reasonabl
Linus Torvalds writes:
> I hate your patch for other reasons, though:
>
>> The problem for read() is addressed in a similar way by introducing
>> a wrapper function in compat that always reads less than 2GB.
>
> Why do you do that? We already _have_ wrapper functions for read(),
> namely xread().
On Aug 19, 2013, at 6:04 PM, Linus Torvalds
wrote:
> I hate your patch for other reasons, though:
>
>> The problem for read() is addressed in a similar way by introducing
>> a wrapper function in compat that always reads less than 2GB.
>
> Why do you do that? We already _have_ wrapper functio
On Mon, Aug 19, 2013 at 8:41 AM, Steffen Prohaska wrote:
>
> The reason was that read() immediately returns with EINVAL if nbyte >=
> 2GB. According to POSIX [1], if the value of nbyte passed to read() is
> greater than SSIZE_MAX, the result is implementation-defined.
Yeah, the OS X filesystem l
8 matches
Mail list logo