[Nbd] Earn Benefits worth Rs 20000 with your Credit Card

--> Copyright � 2015 - RBL Bank Ltd. | http://panela.pick2offers.com/ltrack?id=cAlFWVQBFUxBWxgBFEVFWVAFFwk=R1lXBR1EQRUKU0BYEgwKVFYUGSkIWFcBBkcXXlEHFgwCXlYSEEcKVFA==14772=

[Nbd] Get a free credit Health check online

Get your Free Credit Score & Analysis Online Unlock your Credit Potential - Much more than a free credit score We help you: Get offers from over 20+ lenders willing to lend to your credit profile Improve your Credit Score and resolve issues online Reduce EMI costs on existing borrowings First

[Nbd] Get your Dream Home Now !

Yes!! It’s True, Now Get Home Loan e-Approval Instantly *Minimum Paper Work Required Apply Online Now

[Nbd] [PATCH v3 0/2] block size extension

Applies on top of Alex's v7 SHOULD/MUST/MAY patch. In v3: Rework NBD_OPT_GO reply (yet again), where the first patch introduces the framework of NBD_REP_INFO/NBD_REP_EXPORT and the second extends the framework with NBD_INFO_BLOCK_SIZE. Add NBD_OPT_BLOCK_SIZE for the client to advertise that it

[Nbd] [PATCH v3 2/2] doc: Add details on block sizes

Existing NBD servers often have limitations, such as requiring actions to be aligned to block sizes or limiting maximum transactions to avoid denial of service attacks; for example, qemu's NBD server refuses any transaction larger than 32M. But to date, clients have to learn these limitations via

[Nbd] [PATCH v3 1/2] doc: Use dedicated reply types for NBD_OPT_INFO/GO

Since NBD_OPT_INFO and NBD_OPT_GO are experimental, we still have a chance to fix them up before promoting them to stable. Attempting to reuse NBD_OPT_SERVER as the reply to NBD_OPT_INFO and NBD_OPT_GO has a few problems: clients must be prepared to parse two different styles of the reply, based

Re: [Nbd] [PATCHv7] docs/proto.md: Clarify SHOULD / MUST / MAY etc

On 04/12/2016 12:35 PM, Alex Bligh wrote: > These are changes which possibly have semantic effect > > * Clarify that SHOULD / MUST / MAY etc. when in capitals have an > RFC 2119 meaning using the wording within that RFC. > > * Fix some lowercase use of these words which actually were > meant

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On 13 Apr 2016, at 17:09, Alex Bligh wrote: > Here's what > https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt > has to say: Aha. I found the original thread where I asked about this (it was on linux-fsdevel):

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On 13 Apr 2016, at 16:39, Eric Blake wrote: >> >> I wouldn't want to loose that. So if the client sends NBD_CMD_DISC >> without waiting for all his inflight commands to complete, those >> inflight commands may not be executed at all, because the server >> is free to process

Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

On 13 Apr 2016, at 16:26, Eric Blake wrote: >> Having thought a bit more about this, I think we might (after all) >> need a client flag which says "I respect minimum block sizes" >> or "I respect block sizes" very early on in the negotiation. >> >> The reason why is this. >>

Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

On 13 Apr 2016, at 16:24, Eric Blake wrote: >>> >>> +* `NBD_INFO_MAXIMUM_BLOCK` (4) >>> + >>> + The *info length* MUST be 4, and represents the maximum block >>> + size. See the "Block sizes" section for further requirements on >>> + its value. >>> + >>>

Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

On 13 Apr 2016, at 15:51, Eric Blake wrote: > On 04/13/2016 05:41 AM, Alex Bligh wrote: >> >> On 13 Apr 2016, at 12:05, Alex Bligh wrote: >> Having a default for preferred block size sounds sane, although it might be better to switch it to 4096

Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

On 04/13/2016 05:41 AM, Alex Bligh wrote: > > On 13 Apr 2016, at 12:05, Alex Bligh wrote: > >>> Having a default for preferred block size sounds sane, although it might >>> be better to switch it to 4096 (which is what most conversations seem to >>> use today) rather than 512.

Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

On 04/13/2016 01:27 AM, Wouter Verhelst wrote: > Eric, > > On Tue, Apr 12, 2016 at 06:16:54PM -0600, Eric Blake wrote: >> Existing NBD servers often have limitations, such as requiring >> actions to be aligned to block sizes or limiting maximum >> transactions to avoid denial of service attacks;

Re: [Nbd] [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/13/2016 06:38 AM, Pavel Borzenkov wrote: >> I'm also starting to think that it is worth FIRST documenting an >> extension for advertising block sizes, so that we can then couch >> BLOCK_STATUS in those terms (a server MUST NOT subdivide status into >> finer granularity than the advertised

Re: [Nbd] [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

Hi Eric, On Thu, Apr 07, 2016 at 10:10:58AM -0600, Eric Blake wrote: > On 04/07/2016 04:38 AM, Vladimir Sementsov-Ogievskiy wrote: > > On 05.04.2016 16:43, Paolo Bonzini wrote: > >> > >> On 05/04/2016 06:05, Kevin Wolf wrote: > >>> The options I can think of is adding a request field "max number

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Wouter, On 13 Apr 2016, at 12:44, Wouter Verhelst wrote: > Hi Alex, > > On Wed, Apr 13, 2016 at 11:25:02AM +0100, Alex Bligh wrote: >> Wouter, >> +A client MAY use a soft disconnect to terminate the session +whenever it wishes, provided that there are no outstanding

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Hi Alex, On Wed, Apr 13, 2016 at 11:25:02AM +0100, Alex Bligh wrote: > Wouter, > > >> +A client MAY use a soft disconnect to terminate the session > >> +whenever it wishes, provided that there are no outstanding > >> +replies to options. > > > > NAK. A client MAY use a soft disconnect *at any

Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

On 13 Apr 2016, at 12:05, Alex Bligh wrote: >> Having a default for preferred block size sounds sane, although it might >> be better to switch it to 4096 (which is what most conversations seem to >> use today) rather than 512. > > +1 Actually doubly +1, as this in theory

Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

On 13 Apr 2016, at 08:27, Wouter Verhelst wrote: > Currently, there are no default minimum or maximum block sizes, and > therefore they are effectively limited to "1 byte" for the minimum block > size, and "the size of the device" for the maximum block size. > > I do agree that

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

Eric, Agree with the nits - many of them were from the mailing list message which of course I then didn't check before copying into the commit message. Re the substance: >> +* Transmission mode can be entered (by the client sending >> + `NBD_OPT_EXPORT_NAME` or by the server responding to an

Re: [Nbd] [PATCH] Docs: improve description of disconnection methods

On Tue, Apr 12, 2016 at 08:31:33PM +0100, Alex Bligh wrote: > Improve the documentation as per the mailing list discussion. > Here's what we deciced (broadly). > > * One side MAY drop the connection if the other end violates a > MUST condition. > > * The server MUST drop the connection in the