On Thu, Sep 01, 2022 at 12:14:40PM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 01, 2022 at 04:01:39PM +0800, Ming Lei wrote:
> > Maybe you should use one nbd disk, which has the closest code path
> > with nbdublk.
>
> Good idea - I have started a heavy test using nbd.ko as the
> backing.
On 09/02/22 01:35, Eric Blake wrote:
> On Thu, Sep 01, 2022 at 05:33:43PM +0100, Richard W.M. Jones wrote:
>>> How about the following wording:
>>>
>>> Returns true if libnbd was compiled with support for the C
>>> family of sockets, or false if not. Note that on the Linux
>>> operating system,
On 09/01/22 22:46, Richard W.M. Jones wrote:
> On Thu, Sep 01, 2022 at 03:38:34PM -0500, Eric Blake wrote:
>> On Thu, Sep 01, 2022 at 05:29:21PM +0100, Richard W.M. Jones wrote:
>>> On Wed, Aug 31, 2022 at 09:39:20AM -0500, Eric Blake wrote:
Add a new control knob
On 09/02/22 00:00, Eric Blake wrote:
> On Thu, Sep 01, 2022 at 05:25:55PM +0100, Richard W.M. Jones wrote:
>>>
>>> Can we introduce some xfuncname pattern for these "state machine" C
>>> files? The STATE_MACHINE hunk header is totally useless. I'd like
>>> "NEWSTYLE.OPT_META_CONTEXT.START". :)
>>
FYI, nbdublk is now available in Fedora Rawhide, along with the
dependencies liburing 2.2 and ubdsrv.
https://koji.fedoraproject.org/koji/buildinfo?buildID=2056223
Thanks for your help.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming
On Fri, Sep 02, 2022 at 11:01:36AM +0200, Laszlo Ersek wrote:
> On 09/01/22 22:46, Richard W.M. Jones wrote:
> > On Thu, Sep 01, 2022 at 03:38:34PM -0500, Eric Blake wrote:
> >> On Thu, Sep 01, 2022 at 05:29:21PM +0100, Richard W.M. Jones wrote:
> >>> On Wed, Aug 31, 2022 at 09:39:20AM -0500, Eric
Increment statistics counters every time we send or receive bytes, as
well as every time we send or receive a magic number delineating a
portion of the data stream (the server's initial NBD_MAGIC,
handshaking NBD_NEW_VERSION/NBD_OPT answered by one or more
NBD_REP_MAGIC replies, and transmission
This proves that the stat counters increment as desired, as well as
proving that our RUInt32 generator type works.
This commit is also a showcase of whether I can do 64-bit math in
various languages (C's terseness in 'a == b + (c > d)' is annoying to
replicate in languages that don't like playing
The next patch will add some APIs that expose long-term statistics
counters. A counter is always accessible (no need to return -1; if
the handle is new the count is still 0, and even after the handle is
in DEAD the counter is still useful). But it is also long-running;
the existing RUInt might
With this, I'll be able to clean up test 3/12 in the pending
opt_set_meta_context() series to test whether filtering was done
client- or server-side.
Eric Blake (4):
internal: Track traffic stats
generator: Add RUInt64 for 64-bit counters without error
api: Add new nbd_stats_*() statistics
I was trying to write a test that determined whether a failure was due
to a short-circuit test on the client side or an actual failure
returned by the server. Such a test is a lot easier if we can watch
status counters increase according to how much traffic goes over the
wire. We may add more
dd writes progress messages to stderr, with no complaints. Having
nbdcopy open /dev/tty instead of reusing stderr to write messages
litters the output of a terminal during an interactive 'make check',
which is rather distracting, even though that test also ran a second
copy using a different fd
On Fri, Sep 02, 2022 at 06:58:53PM +0100, Richard W.M. Jones wrote:
> On Fri, Sep 02, 2022 at 10:25:38AM -0500, Eric Blake wrote:
> > dd writes progress messages to stderr, with no complaints. Having
> > nbdcopy open /dev/tty instead of reusing stderr to write messages
> > litters the output of a
On Fri, Sep 02, 2022 at 10:25:38AM -0500, Eric Blake wrote:
> dd writes progress messages to stderr, with no complaints. Having
> nbdcopy open /dev/tty instead of reusing stderr to write messages
> litters the output of a terminal during an interactive 'make check',
> which is rather distracting,
14 matches
Mail list logo
