From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDPcw-0006cg-Ii for qemu-devel@nongnu.org; Thu, 16 Jun 2016 01:14:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDPcv-0007t3-KA for qemu-devel@nongnu.org; Thu, 16 Jun 2016 01:14:02 -0400 Date: Thu, 16 Jun 2016 13:13:49 +0800 From: Fam Zheng Message-ID: <20160616051349.GG12178@ad.usersys.redhat.com> References: <1465939839-30097-1-git-send-email-eblake@redhat.com> <1465939839-30097-6-git-send-email-eblake@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1465939839-30097-6-git-send-email-eblake@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 05/17] nbd: Advertise realistic limits to block layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, kwolf@redhat.com, Paolo Bonzini , qemu-block@nongnu.org, Max Reitz On Tue, 06/14 15:30, Eric Blake wrote: > We were basing the advertisement of maximum discard and transfer > length off of UINT32_MAX, but since the rest of the block layer > has signed int limits on a transaction, nothing could ever reach > that maximum, and we risk overflowing an int once things are > converted to byte-based rather than sector-based limits. What's > more, we DO have a much smaller limit: both the current kernel > and qemu-nbd have a hard limit of 32M on a read or write > transaction, and while they may also permit up to a full 32 bits > on a discard transaction, the upstream NBD protocol is proposing > wording that without any explicit advertisement otherwise, > clients should limit ALL requests to the same limits as read and > write, even though the other requests do not actually require as > many bytes across the wire. So the better limit to tell the > block layer is 32M for both values. > > Signed-off-by: Eric Blake > Reviewed-by: Fam Zheng