Hi,
I have been trying to get nbd to work, the server is 2.4.18-pre7-ac2 and
the client is 2.5.7, and the exported device is /dev/hda1 a 15GiB partition.
I found and downloaded nbd.14.tar.gz. Is this the latest and greatest?
Compiling the package gives several warnings and indeed the nbd-server
doesn't work. The size auto detection code is completely bogus because it
submits 64 bit variables via their address to system calls which only take
32 bit variables so you see silly things like
es = (u64)-1
turning into
es = 0xffffffff01d4b139
instead of
es = 0x000000000whatever
You either need to use 64 bit variants of the calls or you need to submit a
32bit variable to the call, e.g. es32, and then expand it via es = (u64)es32.
So I got past this and fixed size detection for myself.
Now I get it to serve the first request but then it dies.
On the server I see:
[aia21@storm:~/nbd]$ ./nbd-server 5555 /dev/hda1 -r
Entering request loop!
1: *READ from 0 (0) len 4096, exp->buf, buf->net, +OK!
2: *[aia21@storm:~/nbd]$
And on the client I see:
[aia21@drop nbd]$ dd if=/dev/nd1 of=ffff bs=1024 count=8
NBD: receive - sock=-301251788 at buf=-65871580, size=16 returned 0.
NBD: Recv control failed.(result 0)
req should never be null
Kernel call returned.Closing: que, sock, done
NBD, minor 0: Request when not-ready.
dd: reading `/dev/nd0': Input/output error
4+0 records in
4+0 records out
[aia21@drop nbd]$
The contents of the 4kiB of data transmitted are correct so we are
definitely on the right track but something seems to be aborting the
request loop in the server program.
I will be looking into this as I _need_ this functionality very urgently
but I thought I would ask in case I have an out of data package of the nbd
utilities or someone has already fixed this and would like to share their
code with me...
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Just to keep interested parties informed:
Thanks to Steven Whitehouse I found out that the latest nbd client/server
user space programs are in CVS on Sourceforge (the kernel nbd documentation
needs updating to point to http://sf.net/projects/nbd)...
And I have just submitted a patch to Steven to make the nbd-server 64-bit
clean on 32-bit machines and to allow proper auto detection of device size.
Hopefully we will see it entering the CVS soon. Otherwise patch is
available on request from me. (-:
Mounting a NTFS 15GiB partition over nbd (using ntfs tng driver) gave me a
data throughput of 7-10MiB/sec over 100MBit ethernet (going via switch and
a hub) which is quite impressive. (-:
Best regards,
Anton
At 13:10 24/03/02, Anton Altaparmakov wrote:
>Hi,
>
>I have been trying to get nbd to work, the server is 2.4.18-pre7-ac2 and
>the client is 2.5.7, and the exported device is /dev/hda1 a 15GiB partition.
>
>I found and downloaded nbd.14.tar.gz. Is this the latest and greatest?
>
>Compiling the package gives several warnings and indeed the nbd-server
>doesn't work. The size auto detection code is completely bogus because it
>submits 64 bit variables via their address to system calls which only take
>32 bit variables so you see silly things like
>
>es = (u64)-1
>
>turning into
>
>es = 0xffffffff01d4b139
>
>instead of
>
>es = 0x000000000whatever
>
>You either need to use 64 bit variants of the calls or you need to submit
>a 32bit variable to the call, e.g. es32, and then expand it via es = (u64)es32.
>
>So I got past this and fixed size detection for myself.
>
>Now I get it to serve the first request but then it dies.
>
>On the server I see:
>
>[aia21@storm:~/nbd]$ ./nbd-server 5555 /dev/hda1 -r
>Entering request loop!
>1: *READ from 0 (0) len 4096, exp->buf, buf->net, +OK!
>2: *[aia21@storm:~/nbd]$
>
>And on the client I see:
>
>[aia21@drop nbd]$ dd if=/dev/nd1 of=ffff bs=1024 count=8
>NBD: receive - sock=-301251788 at buf=-65871580, size=16 returned 0.
>NBD: Recv control failed.(result 0)
>req should never be null
>Kernel call returned.Closing: que, sock, done
>NBD, minor 0: Request when not-ready.
>dd: reading `/dev/nd0': Input/output error
>4+0 records in
>4+0 records out
>[aia21@drop nbd]$
>
>The contents of the 4kiB of data transmitted are correct so we are
>definitely on the right track but something seems to be aborting the
>request loop in the server program.
>
>I will be looking into this as I _need_ this functionality very urgently
>but I thought I would ask in case I have an out of data package of the nbd
>utilities or someone has already fixed this and would like to share their
>code with me...
>
>Best regards,
>
>Anton
>
>
>--
> "I've not lost my mind. It's backed up on tape somewhere." - Unknown
>--
>Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
>Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
>ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Hi,
>
> Just to keep interested parties informed:
>
> Thanks to Steven Whitehouse I found out that the latest nbd client/server
> user space programs are in CVS on Sourceforge (the kernel nbd documentation
> needs updating to point to http://sf.net/projects/nbd)...
>
> And I have just submitted a patch to Steven to make the nbd-server 64-bit
> clean on 32-bit machines and to allow proper auto detection of device size.
> Hopefully we will see it entering the CVS soon. Otherwise patch is
> available on request from me. (-:
>
Its all there now and as you suggested I've added the configure script so
autoconf is no longer required to build it.
> Mounting a NTFS 15GiB partition over nbd (using ntfs tng driver) gave me a
> data throughput of 7-10MiB/sec over 100MBit ethernet (going via switch and
> a hub) which is quite impressive. (-:
>
Also there is the zerocopy nbd patch I did for my UKUUG talk last year on my
patches page: http://www.chygwyn.com/~steve/kpatch/ its out of date now
but my plan is to update and sumbit it for 2.5 in the next few weeks or so.
It should make things even faster or at least more efficient if we are maxing
out the network already :-)
Steve.
On Sun, 24 Mar 2002, Steven Whitehouse wrote:
> > Just to keep interested parties informed:
> >
> > Thanks to Steven Whitehouse I found out that the latest nbd client/server
> > user space programs are in CVS on Sourceforge (the kernel nbd documentation
> > needs updating to point to http://sf.net/projects/nbd)...
> >
> > And I have just submitted a patch to Steven to make the nbd-server 64-bit
> > clean on 32-bit machines and to allow proper auto detection of device size.
> > Hopefully we will see it entering the CVS soon. Otherwise patch is
> > available on request from me. (-:
> >
> Its all there now and as you suggested I've added the configure script so
> autoconf is no longer required to build it.
Great.
> > Mounting a NTFS 15GiB partition over nbd (using ntfs tng driver) gave me a
> > data throughput of 7-10MiB/sec over 100MBit ethernet (going via switch and
> > a hub) which is quite impressive. (-:
> >
> Also there is the zerocopy nbd patch I did for my UKUUG talk last year on my
> patches page: http://www.chygwyn.com/~steve/kpatch/ its out of date now
> but my plan is to update and sumbit it for 2.5 in the next few weeks or so.
> It should make things even faster or at least more efficient if we are maxing
> out the network already :-)
Oooh. Cool. (-:
Talking about performance. When streaming I noticed that the request size
increases until it reaches 128kiB.
This would be all fine except that nbd (or other part of the kernel?)
splits those up into two requests, one 130048 bytes and one 1024 bytes
which is not the best for performance. Note I am running a kernel with
memmory debugging (and everything else debugging) enabled so that might be
interfering here, haven't tried without debugging support in the kernel
yet... Just thought you might want to know... (The client here is 2.5.7 +
latest nbd-client from nbd CVS on SF.net.)
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Hi!
> I have been trying to get nbd to work, the server is 2.4.18-pre7-ac2 and
> the client is 2.5.7, and the exported device is /dev/hda1 a 15GiB partition.
>
> I found and downloaded nbd.14.tar.gz. Is this the latest and
> greatest?
Latest is the one in cvs at nbd.sf.net. Please use that.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi!
> > Just to keep interested parties informed:
> >
> > Thanks to Steven Whitehouse I found out that the latest nbd client/server
> > user space programs are in CVS on Sourceforge (the kernel nbd documentation
> > needs updating to point to http://sf.net/projects/nbd)...
> >
> > And I have just submitted a patch to Steven to make the nbd-server 64-bit
> > clean on 32-bit machines and to allow proper auto detection of device size.
> > Hopefully we will see it entering the CVS soon. Otherwise patch is
> > available on request from me. (-:
> >
> Its all there now and as you suggested I've added the configure script so
> autoconf is no longer required to build it.
Hmm, I do not think I like autogenerated files in CVS [they are
autogenerated, so you'll get big changes looking at diff -u, they add
lot of stuff to cvs history, etc.]. Would it be possible to remove
configure, and instead do .tar.gz release for people to use?
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi,
[snip]
> > >
> > Its all there now and as you suggested I've added the configure script so
> > autoconf is no longer required to build it.
>
> Hmm, I do not think I like autogenerated files in CVS [they are
> autogenerated, so you'll get big changes looking at diff -u, they add
> lot of stuff to cvs history, etc.]. Would it be possible to remove
> configure, and instead do .tar.gz release for people to use?
>
Yes, I'm quite happy to do it that way if you prefer. I had been thinking
that we ought to put a tar ball up for convenience,
Steve.