Re: [Qemu-block] [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support"

[Markus Armbruster]

Max Reitz <address@hidden> writes:

> On 03.11.2016 08:56, Markus Armbruster wrote:
>> Max Reitz <address@hidden> writes:
>> 
>>> See patch 3 for the reason why we have actually never supported TFTP at
>>> all (except for very small files (i.e. below 256 kB or so)).
>> 
>> Care to explain why it works "for very small files" in a bit more
>> detail?  PATCH 3 gives a "does not support byte ranges" hint, but to go
>> from there to "very small files", you need to know more about how the
>> block layer works than I can remember right now.
>
> Our curl block drivers caches data and uses a readahead cache, which by
> default has a size of 256 kB. Therefore, if the start of the file is
> read first (which it usually is, if just for format probing), then the
> correct data will be read for that size.
>
> Yes, you can adjust the readahead size. No, I cannot guarantee that
> there are no users that just set readahead to the image size and thus
> made it work. I can't really imagine that, though, because at that point
> you can just copy the file to tmpfs and have the same result.
>
> Also, if I were a user, I probably wouldn't use 256 kB images, and thus
> I would just notice tftp to be broken. I don't think I would experiment
> with the readahead option to find out that it works if I set it to the
> image size and then just use it that way. I definitely think I would
> give up before that and just copy the file to the local system.

I'm not trying to make you explain why it's okay to drop TFTP.  I'm
trying to make you explain what exactly worked and what exactly didn't.
Such explanations generally involve a certain degree of "why".

Your first paragraph provides a few more hints, but I'm still guessing.
Here's my current best guess:

* Commonly, images smaller than 256 KiB work, and larger images don't.

* "Don't work" means the block layer returns garbled data.

* "Commonly" means when the first read is for offset zero.  Begs the
  question when exactly that's the case.  You mentioned format probing.
  What if the user specified a format?  It's okay not to answer this
  question.  I'm not demanding exhaustive analysis, I'm fishing for a
  better commit message.  Such a message may leave some of its questions
  unanswered.