NBD kernel module

[prpr]

I've been wondering whether it's possible to make an HD T2 run on a network block device using NBD.
I've (cross-)compiled the client (with a couple of changes) and it works as far as it can without the nbd.ko driver module.
I have no idea how to build the latter. Can anyone advise please? The kernel looks like it ought to support this...

 

[af123]

You need to download the kernel source from the Humax open source site along with the kernel configuration file that's on there. That may be enough for you to build the missing module although you won't be able to build a working kernel without extra patches and configuration parameters that they haven't made available!

I've put a built module at http://hpkg.tv/misc/nbd.ko if you want to use it for testing.

humax# sha1sum nbd.ko
47ae3d76cbe3a3b95fdff3b2c951e8b18cf6bded  nbd.ko
humax# insmod nbd.ko
humax# cat /proc/modules
nbd 17616 0 - Live 0xc00ad000
nfsd 107280 6 - Live 0xc00f0000
exportfs 5696 1 nfsd, Live 0xc00aa000
fuse 52336 0 - Live 0xc00be000
bcmdriver 13152 2 - Live 0xc0094000

 

[prpr]

Mixed so far...
1) The module loads OK
2) "ls /sys/block/nbd*" shows 16 entries, which is correct
3) There is nothing in /dev relating to nbd
4) Ran "mknod nbd0 b 43 0" in /dev and it complained about it being read-only
5) Repeated in a writable directory and it created the block device (is this a valid thing to do?)
6) Connected the client to the server OK using this device
7) Ran fdisk on the device and created a partition table
8) Reading it back causes some weirdness in geometry
9) Formatted partiton 1 as ext2 and mounted it somewhere and it works
10) Copied a file to it
11) Unmounted, disconnected, re-connected, re-mounted and file still there

 

[af123]

That sounds like good progress. /dev is part of read-only flash but it's legitimate to create the device elsewhere as you've done.

 

[Black Hole]

???

 

[prpr]

In normal operation, the client seems to have two instances running (have to check on Ubuntu to see if it does that there as well). When you disconnect, it leaves one running and a socket in CLOSE_WAIT state. Not sure which is cause and which is effect.

 

[prpr]

???

Whoosh

All in the fullness of time BH, subject to doing some performance tests and sorting out the snags.

 

[raydon]

What platform are you running the NBD server on ?

 

[prpr]

At the moment, just for initial testing, an Ubuntu 14.04LTS VM running under Virtualbox on Mint 17.2. The VM disk image is on SSD.

 

[raydon]

Good stuff. Be interesting to see the results if you mount it under 'My Video', and copy a recording over.

 

[Black Hole]

We can already do that by other means, so I guess the point is to be able to record directly to an external something. But then the recording will still require decryption.

 

[prpr]

Good stuff. Be interesting to see the results if you mount it under 'My Video', and copy a recording over.

Initial testing showed no problems (once I'd moved the spare HDR on to the wired network - wireless is completely hopeless, as I'd expected) and simple "dd" tests with the right block size topped out at about 12MB/s which ain't bad for 100Mbps ethernet.
So I allocated a 250GB volume from LVM on my main machine's HD-RAID, formatted it ext2 and shared the block device directly with the nbd-server (previously I was using a small-ish file-as-a-disk container in the VM), ran up the client on the HDR, checked with e2fsck that it liked it (it did) and mounted it.
Did some file copy tests and got about 11.5MB/s both to and fro. Real playback tests were fine.
I then remounted it over "My Video" and tried some recordings - two HD recordings, a reverse spool of one of them and a decrypt all going at the same time produced some nice big peak load figures (probably 80Mbps at the highest) but the average in normal use was a lot less.
I couldn't make it glitch at all, which I was rather impressed with.

Next test is to try it on the HD, but my USB stick has gone read-only (the whole physical device! - that was a waste of £3.29) and I'm largely out of time for this week anyway.

 

[prpr]

That sounds like good progress. /dev is part of read-only flash but it's legitimate to create the device elsewhere as you've done.

The trouble with manually creating nbd0 not in /dev is that it doesn't create nbd0p1 when you create a partition with fdisk. This caused me all sorts of confusion as I ended creating a partition and then formatted the disk, rather than the partition, then wondered where my partition table had gone (duh!). Creating nbd0p1 manually doesn't help either.
I guess this is why there are all those preconfigured devices in /dev
Are these things modifiable with a special custom firmware build (not that I'm asking for it at this point, just enquiring in theory)?

 

[prpr]

We can already do that by other means, so I guess the point is to be able to record directly to an external something.

Yes, it puts the disk at the other end of the network cable, rather that poking out the USB socket in an inelegant manner.

But then the recording will still require decryption.

I know that, but that wasn't what I was investigating.

 

[af123]

We can already do that by other means, so I guess the point is to be able to record directly to an external something. But then the recording will still require decryption.

This could allow you to run a diskless HDR (the disk being on a NAS somewhere).

 

[af123]

Are these things modifiable with a special custom firmware build (not that I'm asking for it at this point, just enquiring in theory)?

/dev will always be read-only so even if /dev/nbd0 was added to the flash filesystem I don't think it will completely solve your problem.
However, you can create a writeable overlay mount during boot in the same way that the screensaver packages do (from /mod/boot/xinit.d/script)
You need to do something like copy the contents of /dev to /tmp/dev and then mounting /tmp/dev over /dev.

 

[prpr]

You need to download the kernel source from the Humax open source site along with the kernel configuration file that's on there. That may be enough for you to build the missing module

What's the magic incantation then? I can get it to compile all the .o files, but nothing on God's Earth will generate a .ko

 

[xyz321]

If you haven't already done so, copy the config file to the root of the kernel src as '.config'. You can edit it manually to add nbd but it is normally recommended to use 'make config' to make changes since some options are dependent upon others. You need to set the CONFIG_BLK_DEV_NBD option to 'm' to create a module for nbd.

make CROSS_COMPILE=mipsel-linux- config
make CROSS_COMPILE=mipsel-linux- modules

 

[prpr]

If you haven't already done so, copy the config file to the root of the kernel src as '.config'.

Yes, I did that, once I worked out (the hard way) what is had to be called and where it had to go.

You can edit it manually to add nbd but it is normally recommended to use 'make config' to make changes since some options are dependent upon others.

The trouble is, it takes for-bloody-ever in interactive mode and you get so bored your hand just sits on the Return key and before you know it you've missed it. I've tried it both ways and there is only the one line changed anyway so a manual edit is much easier.

You need to set the CONFIG_BLK_DEV_NBD option to 'm' to create a module for nbd.

Ah, thanks, that is the magic and not obvious to anyone who doesn't already know. I was putting 'y'. How am I supposed to know? (rhet.)

make CROSS_COMPILE=mipsel-linux- config
make CROSS_COMPILE=mipsel-linux- modules

I used "make ARCH=mips CROSS_COMPILE=mipsel-linux-" and everything builds (*), some with some disturbing warnings.

(*) Once I'd downgraded "make" to version 3.81 of course, which wasted ages in itself, 'cos nothing later works.

Anyway, the good news is that the module builds. But the bad news is that it's 64 bytes shorter than af123's version and segfaults when I try and use it, which of course takes the box down. Comparing one with the other, the difference seems to come in between offsets 0x310 and 0x1580 in the .ko file.

 

[af123]

'make menuconfig' is better than the interactive series of questions.
I've never tried using ARCH= in the command line... may be part of the problem.