Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 11 May 2016, at 22:06, Wouter Verhelst wrote: > On Tue, May 10, 2016 at 04:08:50PM +0100, Alex Bligh wrote: >> What surprises me is that a release kernel is using experimental >> NBD extensions; there's no guarantee these won't change. Or does >> fstrim work some other way? >

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 11 May 2016, at 22:12, Wouter Verhelst wrote: > On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote: >> On 10 May 2016, at 16:29, Eric Blake wrote: >>> So the kernel is currently one of the clients that does NOT honor block >>> sizes, and as such,

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote: > On 10 May 2016, at 16:29, Eric Blake wrote: > > So the kernel is currently one of the clients that does NOT honor block > > sizes, and as such, servers should be prepared for ANY size up to > > UINT_MAX (other than

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 09:29:23AM -0600, Eric Blake wrote: > On 05/10/2016 09:08 AM, Alex Bligh wrote: > > Eric, > > > >> Hmm. The current wording of the experimental block size additions does > >> NOT allow the client to send a NBD_CMD_TRIM with a size larger than the > >> maximum

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 04:08:50PM +0100, Alex Bligh wrote: > What surprises me is that a release kernel is using experimental > NBD extensions; there's no guarantee these won't change. Or does > fstrim work some other way? What makes you say NBD_CMD_TRIM is experimental? It's been implemented

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 11/05/2016 16:55, Alex Bligh wrote: >> > Then I think I will propose a doc patch to the extension-info branch >> > that adds new INFO items for NBD_INFO_TRIM_SIZE and >> > NBD_INFO_WRITE_ZERO_SIZE (if requested by client and replied by server, >> > then this can be larger than the normal

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 11 May 2016, at 15:08, Eric Blake wrote: > Then I think I will propose a doc patch to the extension-info branch > that adds new INFO items for NBD_INFO_TRIM_SIZE and > NBD_INFO_WRITE_ZERO_SIZE (if requested by client and replied by server, > then this can be larger than

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 05/11/2016 03:38 AM, Paolo Bonzini wrote: > > > On 10/05/2016 18:23, Alex Bligh wrote: >>> Is there a use case where you'd want to split up a single big TRIM request >>> in smaller ones (as in some hardware would not support it or something)? >>> Even then, it looks like this splitting up

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 10/05/2016 18:23, Alex Bligh wrote: > > Is there a use case where you'd want to split up a single big TRIM request > > in smaller ones (as in some hardware would not support it or something)? > > Even then, it looks like this splitting up would be hardware dependant and > > better implemented

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 04:41:27PM +0100, Alex Bligh wrote: On 10 May 2016, at 16:29, Eric Blake wrote: So the kernel is currently one of the clients that does NOT honor block sizes, and as such, servers should be prepared for ANY size up to UINT_MAX (other than DoS

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 05/10/2016 10:33 AM, Quentin Casasnovas wrote: > Looks like there's an easier way: > > $ qemu-img create -f qcow2 foo.qcow2 10G > $ qemu-nbd --discard=on -c /dev/nbd0 foo.qcow2 > $ mkfs.ext4 /dev/nbd0 > mke2fs 1.42.13 (17-May-2015) > Discarding device blocks: failed - Input/output error

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 10/05/2016 17:38, Alex Bligh wrote: > > and are at the > > mercy of however the kernel currently decides to split large requests). > > I am surprised TRIM doesn't get broken up the same way READ and WRITE > do. The payload of TRIM has constant size, so it makes sense to do that. The kernel

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 05:23:21PM +0100, Alex Bligh wrote: > > On 10 May 2016, at 17:04, Quentin Casasnovas > wrote: > > > Alright, I assumed by 'length of an NBD request', the specification was > > talking about the length of.. well, the request as opposed to

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 05:54:44PM +0200, Quentin Casasnovas wrote: > On Tue, May 10, 2016 at 09:46:36AM -0600, Eric Blake wrote: > > On 05/10/2016 09:41 AM, Alex Bligh wrote: > > > > > > On 10 May 2016, at 16:29, Eric Blake wrote: > > > > > >> So the kernel is currently one

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 10 May 2016, at 17:04, Quentin Casasnovas wrote: > Alright, I assumed by 'length of an NBD request', the specification was > talking about the length of.. well, the request as opposed to whatever is > in the length field of the request header. With

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 04:49:57PM +0100, Alex Bligh wrote: > > On 10 May 2016, at 16:45, Quentin Casasnovas > wrote: > > > I'm by no mean an expert in this, but why would the kernel break up those > > TRIM commands? After all, breaking things up makes sense

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 10 May 2016, at 16:46, Eric Blake wrote: > 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

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 09:46:36AM -0600, Eric Blake wrote: > On 05/10/2016 09:41 AM, Alex Bligh wrote: > > > > On 10 May 2016, at 16:29, Eric Blake wrote: > > > >> So the kernel is currently one of the clients that does NOT honor block > >> sizes, and as such, servers should

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 10 May 2016, at 16:45, Quentin Casasnovas wrote: > I'm by no mean an expert in this, but why would the kernel break up those > TRIM commands? After all, breaking things up makes sense when the length > of the request is big, not that much when it only

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 05/10/2016 09:41 AM, Alex Bligh wrote: > > On 10 May 2016, at 16:29, Eric Blake wrote: > >> So the kernel is currently one of the clients that does NOT honor block >> sizes, and as such, servers should be prepared for ANY size up to >> UINT_MAX (other than DoS handling). >

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote: > Eric, > > On 10 May 2016, at 16:29, Eric Blake wrote: > >>> Maybe we should revisit that in the spec, and/or advertise yet another > >>> block size (since the maximum size for a trim and/or write_zeroes > >>>

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 10 May 2016, at 16:29, Eric Blake wrote: > So the kernel is currently one of the clients that does NOT honor block > sizes, and as such, servers should be prepared for ANY size up to > UINT_MAX (other than DoS handling). Interesting followup question: If the kernel does

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

Eric, On 10 May 2016, at 16:29, Eric Blake wrote: >>> Maybe we should revisit that in the spec, and/or advertise yet another >>> block size (since the maximum size for a trim and/or write_zeroes >>> request may indeed be different than the maximum size for a read/write). >>

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On 05/10/2016 09:08 AM, Alex Bligh wrote: > Eric, > >> Hmm. The current wording of the experimental block size additions does >> NOT allow the client to send a NBD_CMD_TRIM with a size larger than the >> maximum NBD_CMD_WRITE: >>

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

Eric, > Hmm. The current wording of the experimental block size additions does > NOT allow the client to send a NBD_CMD_TRIM with a size larger than the > maximum NBD_CMD_WRITE: > https://github.com/yoe/nbd/blob/extension-info/doc/proto.md#block-size-constraints Correct > Maybe we should