#block-size-constraints
These are server block sizes (obviously) which would normally be passed
from userland client to kernel client via an ioctl. I suspect such
ioctls may not be implemented at the moment, and kernel support for
them would be much appreciated.
--
Alex Bligh
nnel, but cannot assume the NBD connection as a whole
is dead until the last tcp connection has closed?
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
x block layer (or rather how the linux block layer was a few
years ago). I even asked on LKML to verify a few points.
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e/nbd/blob/master/doc/proto.md#ordering-of-messages-and-writes
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> On 15 Sep 2016, at 12:46, Christoph Hellwig wrote:
>
> On Thu, Sep 15, 2016 at 12:43:35PM +0100, Alex Bligh wrote:
>> Sure, it's at:
>>
>> https://github.com/yoe/nbd/blob/master/doc/proto.md#ordering-of-messages-and-writes
>>
>> and that link t
> On 15 Sep 2016, at 12:52, Christoph Hellwig wrote:
>
> On Thu, Sep 15, 2016 at 12:46:07PM +0100, Alex Bligh wrote:
>> Essentially NBD does supports FLUSH/FUA like this:
>>
>> https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt
>>
cticly - in the nbd server you simply need to
> call fdatasync on the backing device or file whenever you get a FLUSH
> requires, and it will do the right thing.
actually fdatasync() technically does more than is necessary, as it
will also flush commands that have been processed, but for which no
> On 15 Sep 2016, at 13:18, Christoph Hellwig wrote:
>
> Yes, please do that. A "barrier" implies draining of the queue.
Done
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.k
e the client code change work around this
issue (somehow).
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> On 15 Sep 2016, at 13:36, Christoph Hellwig wrote:
>
> On Thu, Sep 15, 2016 at 01:33:20PM +0100, Alex Bligh wrote:
>> At an implementation level that is going to be a little difficult
>> for some NBD servers, e.g. ones that fork() a different process per
>> connect
> On 15 Sep 2016, at 13:41, Christoph Hellwig wrote:
>
> On Thu, Sep 15, 2016 at 01:39:11PM +0100, Alex Bligh wrote:
>> That's probably right in the case of file-based back ends that
>> are running on a Linux OS. But gonbdserver for instance supports
>> (e.g.)
he connections).
There's nothing the 'application' (here meaning the kernel or higher level) can
do to mitigate this. Sure it can wait for all the replies, but this doesn't
guarantee the writes have been persisted to non-volatile storage, precisely
because writes may return
ay not (if state is not shared) guarantee
that the write on channel 1 (which has completed) is persisted to non-volatile
media. Obviously if the 'state' is OS block cache/buffers/whatever, it
will, but if it's (e.g.) a user-space per process write-through cache,
it won't.
o the second
> sector, even though the writer never flushed that particular content to
> disk).
Agree
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
ilure case is
one where (by chance) one channel gets the writes, and one channel
gets the flushes. The flush reply is delayed beyond the replies to
unconnected writes (on the other channel) and hence the kernel thinks
replied-to writes have been persisted when they have not been.
The only way to
Wouter,
> On 15 Sep 2016, at 17:27, Wouter Verhelst wrote:
>
> On Thu, Sep 15, 2016 at 05:08:21PM +0100, Alex Bligh wrote:
>> Wouter,
>>
>>> The server can always refuse to allow multiple connections.
>>
>> Sure, but it would be neater to warn the
h you can tell), sending flush on
all channels is the only safe thing to do, without substantial protocol
changes (which I'm not sure how one would do given flush is in a sense
a synchronisation point). I think it's thus imperative this gets fixed
before the change gets merged.
--
ms and fling systems.
What I'm therefore asking for is either:
a) that the server can say 'if you are multichannel, you will need to send
flush on each channel' (best); OR
b) that the server can say 'don't go multichannel'
as part of the negotiation stage. Of course
even with the reference server, this patch is unsafe, and it needs adapting to
send flushes on all channels - yes it might theoretically be possible to
introduce IPC to the current server, but you'd still need some way of tying
together channels from a single client.
--
Alex Bligh
can sort out all the negotiation
of whether it's safe or unsafe within userspace and not bother Josef
about it? I suppose that's fine in that we can at least shorten
the CC: line, but I still think it would be helpful if the protocol
>> Now, in the reference server, NBD_CMD_FLUS
Wouter,
> On 6 Oct 2016, at 10:04, Wouter Verhelst wrote:
>
> Hi Alex,
>
> On Tue, Oct 04, 2016 at 10:35:03AM +0100, Alex Bligh wrote:
>> Wouter,
>>> I see now that it should be closer
>>> to the former; a more useful definition is probably
NBD should work in the face of multiple channels with
> a sane/regular backend.
On which note, I am still not convinced that fsync() provides such
semantics on all operating systems and on Linux on non-block devices.
I'm not sure all those backends are 'insane'! However, i
nbd_set_size args
>
> It'll be in 4.10. Thanks,
Interestingly enough, this is a regression, as the random 3.x kernel I tried
did not show the issue.
Thanks for the fix Josef.
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the
tter if possible
to stick with ioctls, and not introduce either a dependency
on netlink (which would presumably bloat static binaries that
are used early in the boot process). Personally I'd have thought
adding a new NBD ioctl (or extending an existing one) would be
less entropy than
blocksizes properly for the underlying device. Fix this up by
> setting the queue blocksizes and then calling bd_set_size.
Interesting. Some input into the info extension (re blocksizes) would
definitely be appreciated.
--
Alex Bligh
> be relevant to this patch.
Indeed. Specifically, review of the patch from a kernel perspective
would be useful.
--
Alex Bligh
26 matches
Mail list logo
