From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b09s0-00014z-Qt for qemu-devel@nongnu.org; Tue, 10 May 2016 11:46:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b09ry-0008KU-Cv for qemu-devel@nongnu.org; Tue, 10 May 2016 11:46:47 -0400 References: <1462524302-15558-1-git-send-email-quentin.casasnovas@oracle.com> <5731E99C.3000108@redhat.com> <3271D86E-D54C-44FC-9FD6-2E2C51F5FB6D@alex.org.uk> <5731FE53.6010602@redhat.com> From: Eric Blake Message-ID: <5732025C.2050703@redhat.com> Date: Tue, 10 May 2016 09:46:36 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CoUIRPgwc2KgA4vkrfaenGfSJt28wwCQO" Subject: Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Quentin Casasnovas , "qemu-devel@nongnu.org" , "qemu-trivial@nongnu.org" , Paolo Bonzini , "nbd-general@lists.sourceforge.net" , "qemu-stable@nongnu.org" , qemu block This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CoUIRPgwc2KgA4vkrfaenGfSJt28wwCQO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/10/2016 09:41 AM, Alex Bligh wrote: >=20 > On 10 May 2016, at 16:29, Eric Blake wrote: >=20 >> So the kernel is currently one of the clients that does NOT honor bloc= k >> sizes, and as such, servers should be prepared for ANY size up to >> UINT_MAX (other than DoS handling). >=20 > Interesting followup question: >=20 > If the kernel does not fragment TRIM requests at all (in the > same way it fragments read and write requests), I suspect > something bad may happen with TRIM requests over 2^31 > in size (particularly over 2^32 in size), as the length > field in nbd only has 32 bits. >=20 > Whether it supports block size constraints or not, it is > going to need to do *some* breaking up of requests. Does anyone have an easy way to cause the kernel to request a trim operation that large on a > 4G export? I'm not familiar enough with EXT4 operation to know what file system operations you can run to ultimately indirectly create a file system trim operation that large. But maybe there is something simpler - does the kernel let you use the fallocate(2) syscall operation with FALLOC_FL_PUNCH_HOLE or FALLOC_FL_ZERO_RANGE on an fd backed by an NBD device? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --CoUIRPgwc2KgA4vkrfaenGfSJt28wwCQO 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/ iQEcBAEBCAAGBQJXMgJcAAoJEKeha0olJ0NqhB8H+gOeuscTYXJx8Pr94z5uFr+D OzSfptZQpFN99WceNPOLil5RNbujcdAL6yyzBC3DKHzTpLwlqfoX7TDzEth+ON77 ApGUrquPxyyxVtYM0vij+Dt8vTc18c1wJs0TRk6IYhYefeTA1b4lEibZadG+Lkni Ugqd9ecA7gfs8esMe+gnmMDLSSM+Rpb/C0SnLzHnT3+BzlS77H/qLUH0GT80EE39 FMJVbsVpk2xKwoMmHQoh8UYH6DUJI+6P61Z0bFRvIfVken7BumvrXik+JFtbkJop gx81YRKjkgV3IagTcFGwitAzJmYKJkcqPACur0TMb4d6Ahy5/P8NirK5+Ko4OFg= =4i1o -----END PGP SIGNATURE----- --CoUIRPgwc2KgA4vkrfaenGfSJt28wwCQO--