the flags when NBD_DO_IT completes.
Cc: Paul Clements paul.cleme...@steeleye.com
Cc: nbd-gene...@lists.sf.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/block/nbd.c | 10 +-
include/linux/nbd.h | 28 ++--
2 files changed, 23 insertions(+), 15
Update the protocol documentation, and implement it as a dummy
command in the server.
---
This part should be quite uncontroversial, and so should
be patch 2/2 in my kernel series.
However, patch 1 is basically doing the same as the patch
from Alex Bligh that
On 09/13/2011 09:54 AM, Alex Bligh wrote:
Paolo,
--On 13 September 2011 09:49:01 +0200 Paolo Bonzini
pbonz...@redhat.com wrote:
On 09/13/2011 09:47 AM, Folkert van Heusden wrote:
It might be a good way to get a flags-passing mechanism acceptable to
Paul et al ready.
Will that change
On 09/16/2011 12:17 PM, Alex Bligh wrote:
Scratch that, make that need to
have error handling, period.
If PUNCH_HOLE fails, can't you just translate it to a write of zeros
over the area, and use the normal error handling for that? If we
can't TRIM (which might be for reasons quite
On 10/06/2011 12:53 PM, Folkert van Heusden wrote:
Hi,
What is the maximum size of a read/write request? E.g. how much data can
be requested/transmitted using one read or write command?
And can this be limited using a nbd-client command-line setting and/or
nbd protocol handshake?
In
On 09/13/2011 02:28 PM, Alex Bligh wrote:
--On 13 September 2011 14:05:41 +0200 Paolo
Bonzinipbonzini-h+wxahxf7alqt0dzr+a...@public.gmane.org
wrote:
I see you've got support for NBD_TIMEOUT in your patch set too.
That might be better broken out.
It's just ioctl_cmd_to_ascii.
doh.
On 10/26/2011 12:32 AM, Alex Bligh wrote:
OK - I think my tree is based on 2.6.32, so I may have a little
work to do.
Ping?
I haven't had time to look at this, but thanks for the reminder. I will.
The reminder was more for Paul than for you...
Paolo
much unusable, unlike
discard failures.
Signed-off-by: Alex Bligh a...@alex.org.uk
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Cc: Paul Clements paul.cleme...@steeleye.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
Paolo
Il 12/02/2013 22:41, Andrew Morton ha scritto:
There are two problems with shutdown in the NBD driver. The first is
that receiving the NBD_DISCONNECT ioctl does not sync the filesystem;
this is useful because BLKFLSBUF is restricted to processes that have
CAP_SYS_ADMIN, and the NBD client
Il 13/02/2013 16:55, Alex Bligh ha scritto:
But as far as I can test with free servers, the FUA bits have no
advantage over flush. Also, I wasn't sure if SEND_FUA without
SEND_FLUSH is valid, and if so how to handle this combination (treat it
as writethrough and add FUA to all requests?
Il 01/10/2014 22:23, Wouter Verhelst ha scritto:
Hi,
On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote:
Tunneling the entire protocol inside an SSL connection doesn't fix that;
if an attacker is able to hijack your TCP connections and change flags,
then this attacker is also
Il 02/10/2014 13:05, Daniel P. Berrange ha scritto:
On Wed, Oct 01, 2014 at 10:23:26PM +0200, Wouter Verhelst wrote:
Hi,
On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote:
Tunneling the entire protocol inside an SSL connection doesn't fix that;
if an attacker is able to hijack
Il 08/10/2014 20:16, Wouter Verhelst ha scritto:
@@ -242,10 +242,13 @@ Option types
* NBD_OPT_EXPORT_NAME (1)
Choose the export which the client would like to use, and end option
haggling. Data: name of the export, free-form UTF8 text (subject to
limitations by server
On 14/05/2015 12:33, Wouter Verhelst wrote:
On Fri, May 08, 2015 at 12:16:16PM +0200, Paolo Bonzini wrote:
There are two problems:
1) A literal reading of the specification could imply that the server could
not send a reply if fsync() fails, because in that case previous writes
have
On 14/05/2015 13:02, Wouter Verhelst wrote:
I don't think so. Let the client worry about it. They can always
decide to disconnect if they get ENOMEM, or they can get into a recovery
mode with some kind of exponential backoff, or...
Yeah, but then that's not what I meant with fatal. I
On 31/12/2015 12:30, Sitsofe Wheeler wrote:
> Further, re-running qemu-nbd with -v says this:
> nbd.c:nbd_co_receive_request():L1232: len (536870912) is larger than max len
> (33554432)
> which comes from https://github.com/qemu/qemu/blob/v2.5.0/nbd.c#L1230 :
> if (request->len >
On 13/06/2016 23:41, Alex Bligh wrote:
> That's one of the reasons that there is a proposal to add
> STRUCTURED_READ to the spec (although I still haven't had time to
> implement that for qemu), so that we have a newer approach that allows
> for proper error handling without ambiguity on whether
On 14/06/2016 17:02, Alex Bligh wrote:
>
> On 14 Jun 2016, at 14:32, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>>
>> On 13/06/2016 23:41, Alex Bligh wrote:
>>> That's one of the reasons that there is a proposal to add
>>> STRUCTURED_READ t
- Original Message -
> From: "Alex Bligh" <a...@alex.org.uk>
> To: "Wouter Verhelst" <w...@uter.be>
> Cc: "Alex Bligh" <a...@alex.org.uk>, nbd-general@lists.sourceforge.net,
> "Paolo Bonzini" <pbonz...@redhat.c
On 14/06/2016 17:59, Alex Bligh wrote:
>
>> On 14 Jun 2016, at 16:11, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>
>>> To illustrate the problem, look consider what qemu itself would do as
>>> a server if it can't buffer the entire read issued to it.
On 05/04/2016 07:09, Kevin Wolf wrote:
> > TRIM is an advisory operation, so it doesn't make sense to force access
> > to the medium.
>
> I think it does make sense. It means that on completion there is no
> pending discard operation (i.e. either there wasn't a discard or if
> there was, it has
On 04/04/2016 22:03, Alex Bligh wrote:
> So qemu-nbdserver has some idea of 'dirtiness', and you want
> to publish that, and the consumer is qemu (and only qemu),
> because only qemu knows what 'dirtiness' means in the
> sense the server provides it?
The consumer is not QEMU; the consumer is
On 05/04/2016 14:07, Alex Bligh wrote:
> Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA. Specifically
> the latter may be set on any command, and its semantics on commands other
> than NBD_CMD_WRITE need explaining. Further, explain how these relate to
> reordering of commands.
On 05/04/2016 17:16, Alex Bligh wrote:
> > > * Document that sending FUA for commands that do nothing is permissible,
> > > but
> > > 'SHOULD NOT' be done; an existing client does this.
> >
> > Can you send a pointer to the discussion? FUA on reads definitely does
> > *something* in SCSI (it
On 07/04/2016 17:35, Pavel Borzenkov wrote:
> > On 05/04/2016 06:05, Kevin Wolf wrote:
> > > The options I can think of is adding a request field "max number of
> > > descriptors" or a flag "only single descriptor" (with the assumption
> > > that clients always want one or unlimited), but maybe
On 04/04/2016 16:15, Eric Blake wrote:
> qemu already has an existing server implementation option that will
> explicitly search the payload of NBD_CMD_WRITE for large blocks of
> zeroes, and punch holes in the underlying file. For old clients
> that don't know how to use the new
On 24/03/2016 09:26, Wouter Verhelst wrote:
>> >
>> > No, there is no specific reason. Looks like NBD_CMD_FLAG_ZEROES fits the
>> > spec and implementations nicely. So I'll rewrite the extension and add
>> > the flag instead of the whole command.
> Actually, having given this some more
On 24/03/2016 11:32, Alex Bligh wrote:
>> > Now I'm not saying we
>> > need to fully define what it means for a part of the backend to be
>> > "dirty" or not. It's okay to leave part of the meaning in the dark,
>> > leaving that implementation-defined.
> Well, the 3 possible states are:
>
> *
On 23/03/2016 18:58, Wouter Verhelst wrote:
>> +To provide such class of information, `GET_LBA_STATUS` extension adds new
>> +`NBD_CMD_GET_LBA_STATUS` command which returns a list of LBA ranges with
>> +their respective states.
>> +
>> +* `NBD_CMD_GET_LBA_STATUS` (7)
>> +
>> +An LBA range
On 24/03/2016 14:31, Alex Bligh wrote:
> Sorry, I should have been clearer on the states:
>
> bits
> 210
>
> 1-- Unallocated, and hence reads as zero
> -1- Allocated, and reads as zero
> --1 Allocated, and reads as non-zero
>
> So 100 means 'definitely unallocated, will read as zero'.
>
> If
On 24/03/2016 16:25, Eric Blake wrote:
>> However, let's make these bits, so that
>>
>> NBD_STATE_ALLOCATED (0x1), LBA extent is present on the block device
>> NBD_STATE_ZERO (0x2), LBA extent will read as zeroes
>
> Should we flip the sense and call this NBD_STATE_UNALLOCATED (0 means
>
On 24/03/2016 13:17, Alex Bligh wrote:
>>> >> * unallocated
>>> >> * zero
>>> >> * non-zero
>>> >>
>>> >> So the possible replies are a bitfield of those, with a '1' if it 'might'
>>> >> be in that state, i.e.
>>> >>
>>> >> 111 = no idea
>>> >> 110 = might be zero or unallocated, but isn't
On 04/03/2016 10:54, Kevin Wolf wrote:
>>> - pls write the following amount of zeroes in either way (even calling
>>> > >write directly), i.e. ensure that the data is zeroed and the space on
>>> > >the file system is allocated for that.
>> >
>> > IOW, you *don't* want to have a sparse
On 31/03/2016 16:27, Alex Bligh wrote:
> > > IE why not always permit trimming PROVIDED the data always reads back
> > > as zero? This would be far simpler.
> >
> > Because trimming can make future operations more expensive and cause
> > fragmentation (which may not be as bad as it used to be
On 31/03/2016 22:17, Alex Bligh wrote:
>> > In qemu, read+FUA just triggers blk_co_flush() prior to reading; but
>> > that's the same function it calls for write+FUA.
> That's harmless, but unnecessary in the sense that current documented
> behaviour doesn't require it. Perhaps it should?
>
> I
On 31/03/2016 22:34, Eric Blake wrote:
> give me possibly stale data because I accessed
> the underlying storage rather than paying attention to in-flight writes
> that would change what I read".
Overlapping I/O is always unspecified, so you should expect stale data
if a read overlaps an
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
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
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
On 23/04/2016 04:17, Ratna Manoj wrote:
> Ext4 can be fixed with the this patch:
> http://www.spinics.net/lists/linux-ext4/msg51112.html
> It did not make to the kernel. It checks the state of the buffer head
> before committing.
The patch did not make it, but Ted Ts'o proposed an alternative
On 19/07/2016 17:28, Eric Blake wrote:
>> If I'm reading the NBD proto.md correctly, this is not enough if
>> NBD_CMD_FLAG_NO_HOLE is specified. We probably need to use a zeroed buffer
>> with
>> blk_pwrite, or pass a new flag (BDRV_RED_NO_HOLE) to blk_pwrite_zeroes to
>> enforce the
On 20/07/2016 06:37, Fam Zheng wrote:
> Yes, you are right about this, I was confused because "qemu-img map" does not
> report this allocation state after zero write. (No idea why SEEK_DATA doesn't
> hit the fallocate'ed area.)
Apparently it's because it's zeroed.
$ fallocate -z -o 10485760 -l
e (if there is no coordination between the different
> connections, on an image where the writer changes AA to BA then flushes
> then changes to BB, it is still feasible that a reader could see AB
> (pre-flush state of the first sector, post-flush changes to the second
> sector, even thou
On 15/09/2016 17:23, Alex Bligh wrote:
> Paolo,
>
>> On 15 Sep 2016, at 15:07, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>
>> I don't think QEMU forbids multiple clients to the single server, and
>> guarantees consistency as long as there is no
- Original Message -
> From: "Denis V. Lunev" <d...@virtuozzo.com>
> To: "Paolo Bonzini" <pbonz...@redhat.com>
> Cc: "Vladimir Sementsov-Ogievskiy" <vsement...@virtuozzo.com>,
> qemu-de...@nongnu.org, qemu-bl...@nongnu.org
On 27/09/2016 15:28, Denis V. Lunev wrote:
> On 09/27/2016 03:07 PM, Paolo Bonzini wrote:
>>
>> - Original Message -
>>> From: "Denis V. Lunev" <d...@virtuozzo.com>
>>> To: "Paolo Bonzini" <pbonz...@redhat.com>
>>>
On 24/09/2016 14:27, Vladimir Sementsov-Ogievskiy wrote:
> On 24.09.2016 15:06, Vladimir Sementsov-Ogievskiy wrote:
>> On 24.09.2016 00:21, Wouter Verhelst wrote:
>>> On Fri, Sep 23, 2016 at 02:00:06PM -0500, Eric Blake wrote:
My preference would be a new flag to the existing commands, with
On 26/09/2016 14:46, Vladimir Sementsov-Ogievskiy wrote:
> This extension allows big requests for TRIM and WRITE_ZEROES through
> special 'shift' parameter, which means that offset and length should be
> shifted left by several bits.
>
> This is needed for efficient clearing large regions of
On 26/09/2016 15:53, Vladimir Sementsov-Ogievskiy wrote:
> On 26.09.2016 15:51, Paolo Bonzini wrote:
>> This is very ad hoc. Can we instead have a block size common to all
>> commands? Block devices in practice have one, in fact that's why
>> they're called block devices..
49 matches
Mail list logo
