From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2hk8-0007uR-LB for qemu-devel@nongnu.org; Fri, 04 Nov 2016 12:53:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2hk7-0005Ja-Oz for qemu-devel@nongnu.org; Fri, 04 Nov 2016 12:53:28 -0400 References: <20161102175539.4375-1-mreitz@redhat.com> <87y4113sjx.fsf@dusky.pond.sub.org> From: Max Reitz Message-ID: Date: Fri, 4 Nov 2016 17:53:18 +0100 MIME-Version: 1.0 In-Reply-To: <87y4113sjx.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P3vcO2x6xADPuAdiH9o3wIlMdWVSljwHk" Subject: Re: [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-block@nongnu.org, Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P3vcO2x6xADPuAdiH9o3wIlMdWVSljwHk From: Max Reitz To: Markus Armbruster Cc: qemu-block@nongnu.org, Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org Message-ID: Subject: Re: [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support" References: <20161102175539.4375-1-mreitz@redhat.com> <87y4113sjx.fsf@dusky.pond.sub.org> In-Reply-To: <87y4113sjx.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 03.11.2016 08:56, Markus Armbruster wrote: > Max Reitz writes: >=20 >> See patch 3 for the reason why we have actually never supported TFTP a= t >> all (except for very small files (i.e. below 256 kB or so)). >=20 > 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. Max --P3vcO2x6xADPuAdiH9o3wIlMdWVSljwHk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEvBAEBCAAZBQJYHLz+EhxtcmVpdHpAcmVkaGF0LmNvbQAKCRD0B9sAYdXPQCfg B/4gLQPKchYhxXjaggU/jWzbZKSTYDqZJwVlg2asMqLm5yM0BpJLQ7omcw+f81HM oPjGOrPHJ/yh6fFLmWYdSEntJeXA4QV0TMUOSTUhoZKgCck7ENg+FKDO+sp1Hy1L lBX3CEtA6JkqiEtRV+7hI54gOzjy6rT13OfxMdmB/6q2Y7HJSXbtZKavI2cWeHk8 ZB9SHUTfWMjFRST+Tc5GTkKBdcWIo7AUa3C9fiNaW8AF9zZTIMwlQMMAhav/8yy4 Mw1nYkBdi+oWtuixKueg2chooWFvV8wb5dqtNHdHp+iaV1FAiv513FvkyNXRqr10 YDWiEdhhrC8yg0e8UAfrm1E5 =GJob -----END PGP SIGNATURE----- --P3vcO2x6xADPuAdiH9o3wIlMdWVSljwHk--