From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6o0-0004M6-WC for qemu-devel@nongnu.org; Thu, 24 Mar 2016 11:04:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj6nx-0007pO-QV for qemu-devel@nongnu.org; Thu, 24 Mar 2016 11:04:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6nx-0007pH-J2 for qemu-devel@nongnu.org; Thu, 24 Mar 2016 11:04:09 -0400 References: <1458742562-30624-1-git-send-email-den@openvz.org> <1458742562-30624-3-git-send-email-den@openvz.org> <56F2C3D4.6080204@redhat.com> <20160324123006.GF24831@phobos.sw.ru> From: Eric Blake Message-ID: <56F401E7.3030303@redhat.com> Date: Thu, 24 Mar 2016 09:04:07 -0600 MIME-Version: 1.0 In-Reply-To: <20160324123006.GF24831@phobos.sw.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5oNHOXqjqwQiSDse1nlcJXELIr8nDiM9J" Subject: Re: [Qemu-devel] [PATCH 2/2] NBD proto: add GET_LBA_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Borzenkov Cc: nbd-general@lists.sourceforge.net, Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini , Wouter Verhelst , "Denis V. Lunev" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5oNHOXqjqwQiSDse1nlcJXELIr8nDiM9J Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/24/2016 06:30 AM, Pavel Borzenkov wrote: >> Conversely, it would be possible to send less data over the wire, as >> long as we require that all LBA status descriptors cover consecutive >> offsets. That is, having the server reply with offsets is pointless, >> since they can be reconstructed on the client by starting with the >> offset in the client's request, then adding length from each status >> field. Is less network traffic desirable? >=20 > I think it's better to explicitly send the start of each LBA extent. Why? Is the redundancy for something that the client can reconstruct worth the extra safety at the cost of more traffic? > So I'll go with changing 'status' field to 32 bits to avoid > packing/unpacking issues. You may want to do that even if you eliminate the offset field, so that you have 8 bytes per struct (instead of 16). >> >> Do we want to require that the server MUST reply with enough extents t= o >> sum up to the length of the client's request, or are we permitting a >> short reply? >=20 > While the "GET LBA STATUS" command in SCSI allows partial reply, I > believe it'd better to keep things simple and require that the server > must either return a list of extents that covers the whole requested > range, or an error. Make sure you specify whether ranges are allowed to overlap, or must be distinct (I prefer the latter), and whether they must appear in sorted order (which I also prefer) - once you mandate ordered and non-overlapping coverage, client-side validation that the server's answer makes sense is easier (remember, we want the client to detect man-in-the-middle corruption of the server's reply). > Actually, for this command I treat 'command flags' field not as a set o= f > flags, but rather as a plain number representing required mode of > operation. Probably, not a good idea as it doesn't match the rest of th= e > commands. >=20 > I went this way because I didn't want to allow clients to request > several modes simultaneously (e.g. provisioning + dirtiness) in the sam= e > request. This makes server side implementation harder. >=20 > I think I'll just switch to bits to match the rest of the commands and > will add a note, that server should return EINVAL in case several modes= > are requested simultaneously. But you don't need two bits. Just a single bit will do (off for provisioning mode, on for dirty mode). So there are no conflicting modes that can be simultaneously requested, at least in the current definition of a single valid flag bit. (Then again, I did make a suggestion about additional bits, useful only during provisioning mode, that might be used to state that the client is okay if the server coalesces extents that differ only in allocation or only in zeroed content - if we add that bit or two bits, it would be an error to use it while requesting dirty mode). >> then we can express four states: >> >> 0x0 - LBA extent not present, client MUST NOT make assumptions about >> contents, and reads should not be attempted >> 0x1 - LBA extent allocated, reads will succeed but no guarantee on con= tents >> 0x2 - LBA extent not present, but client can treat the extent as zeroe= s >> and reads will succeed >> 0x3 - LBA extent present, client can treat the extent as zeroes and >> reads will succeed >=20 > I'm not sure that clients need this level of details. From client's POV= > 0x2 and 0x3 are the same. No, if the client is trying to EXACTLY copy sparseness, then 0x2 and 0x3 differ on whether the client will punch a hole vs. explicitly allocate zeroes. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --5oNHOXqjqwQiSDse1nlcJXELIr8nDiM9J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJW9AHnAAoJEKeha0olJ0Nq3twH/izN+/36LxCyP87nTgJhBJ/N B5FOjvEf9WYBjiSsUEDfpF1faG2SnLvP29oMMbgwOkY3JS0kXWZz/07+lTF2uXyR AwpUG61wHGma+dKkuFb06gA6PC12C136W2nGhjH2iycmUYe0Bw8f2XDkw/H9mE8E 1lSooiIy5dxyWzBWNqidAng+QV9Z2OKXELv6SaAkU04LfarEdCI4CHFSHO4QZqyZ tC2G3kbL/WL8WjV/0S6nWdyLEiutY5PGyeDsYPd7ougjq9mkvY2Tqy11Jn7Oa8Z2 GKkspR4bktN61fZLwZDtovTbTsE76yl5gU/mpredp7vFEA+Lbej7gZX4Sq/Tlgg= =XE5s -----END PGP SIGNATURE----- --5oNHOXqjqwQiSDse1nlcJXELIr8nDiM9J--