[ENBD] Raw disks, ntfs

[Peter T. Breuer]

"A month of sundays ago Raul Hudea wrote:"
> Does enbd work with raw disk that are not having as filesystem the ext2,
> but ntfs ?

It doesn't work at the file system level, but at the block level. What
you serve from is up to you. It could be a can of beans. It could be
ntfs. It could be nothing.

> Server:
>     Dual processor with RAID5, SCSI, 2.2.17 with reiserfs and crypto
>     serving a raw partition formatated with NTFS( it has win2k )

If it's a raw partition, it's a raw partition. The format (if any) is
immaterial.

>         nbd-server 1090 /dev/rd/c0d1p2
> 
>  Client:
>     Dual processor SCSI with 2.2.17 without ntfs, reiserfs or crypto

In that case how can you possibly talk about an ntfs filesystem? You
don't support it at the clients side!

>     cmd line:
>         nbd-client server-name 1090 server-name /dev/nda

You should be running more than one communication channel, but in any
case I suppose this is nbd 2.4.14? Not nbd 2.2.27? The command line
indicates so. Please tell me.

> /nbd-server 1090 /dev/rd/c0d1p2 -b 1024
> nbd-server: server (-1) opened port #1090 on socket 1
> nbd-server: server (-1) read passwd ok
> nbd-server: server (-1) got cliserv magic ok
> nbd-server: server (-1) sent size 1941166080 ok

The server has opened the resource, and got size 2GB, I think (hard to
read all those digits).

> nbd-server: server (-1) sent sig ok
> nbd-server: server (-1) suggested ro flags 0 ok
> nbd-server: server (-1) received blksize 1024 ok
> nbd-server: server (-1) sent/negotiated blksize 1024 ok
> nbd-server: server (-1) agreed 1 channels ok
> nbd-server: server (-1) selected free port at 1102
> nbd-server: server (-1) posted port 1102 ok
> nbd-server: server (-1) manager started new process group 1270
> nbd-server: server (-1) manager set CHLD USR1 USR2 HUP TERM signal handlers
> nbd-server: server (-1) opened port #1090 on socket 1
> nbd-server: server (-1) read passwd ok
> nbd-server: server (-1) got cliserv magic ok
> nbd-server: server (-1) sent size 1941166080 ok
> nbd-server: server (-1) sent sig ok

Looks OK. But it sent size twice! Oh, I suppose that's OK.

> On client side:
> 
> nbd-client: client (-1) starts introduction sequence on port 1090
> nbd-client: client (-1) got port 1100 ok
> nbd-client: client (-1) introduction sequence ends ok
> nbd-client: Ioctl/1.1 failed: Invalid argument    <---What is this ?

It's a fail. I don't know which nbd version this is so I can't tell you
what it is. You should investigate. Looks like there's no kernel module
loaded, at a guess, or there is a module loaded and it has the wrong
signature. At any rate it's an ioctl fail, so it's a kernel thing.

Failing ioctl number 1.1 would (without looking) indicate a fail
to say hello. Oooooh .. it's a fail to set the blksize:

              if (blksize > 0) {
                  if (setdeviceblksize(self, blksize) < 0) {
                        PERR ("Ioctl/1.1 failed: %m\n");

But have a look in your code. What kind of blksize are you trying
to set? It should be 1024. Add a printout of the blksize and tell us.
Then check what setdeviceblksize does, and then check what the ioctl
does in the driver code.

> nbd-client: Failed/5: Invalid argument              <--- and this ?

Ditti.

> nbd-client: client (-1) introduction bails out on client socket 5

Not surprising.

> Thanks,

Need more data.  nbd version, for one.  Kernel details (smp, up?).
State of the device, is it loaded, output from /proc/nbdinfo, etc.  etc.

The obvious fact is that the kernel module is not responding properly to
simple ioctls.  Given that you have SMP machines, the most likely
hypothesis is that you have kernels compiled for SMP, but you have not
compiled the module for SMP, so your logs are now full of oopses, and a
module that won't accept an ioctl is the least of your problems.


Peter