Connecting a Device with configFS

[Sergej Roytman]

Hi!  I’m not sure this is general enough for the kernel newbie list.  However, it is certainly a newbie question, and I’m not sure it belongs on target-devel, being more of the “I don’t know how to do something simple” variety.  Anyway, if this question belongs somewhere other than kernelnewbies, and you can direct me to that place, I will be grateful for that pointer as well.

I am trying to patch this thing:

http://www.spinics.net/lists/target-devel/msg05630.html

It is a new user space storage backend for LIO.  There’s a couple of patch files in other messages from the thread, which actually make up the implementation.  I confirmed with the target-devel list at kernel.org that this is in fact the planned user space backend to LIO, which is scheduled for the 3.15 kernel.  I am trying to get a jump on using this thing, by installing the pre-release version and becoming familiar with using it, in time for the official release later this year.

So.  I patched the 3.13 source and built the resulting kernel, with no problems.  insmod-ed the resulting .ko.  The program in the message which I linked, basically, sets up structures in /sys/config, and then puts the new backend through its paces.  To do these things by hand would make a script something like the following.  And I note that when I mkdir certain pseudo-directories in configFS and examine them, additional structure is getting added, as it should be, indicating that the kernel module is installed and active, and calling its callback functions.

  # #!/bin/sh
  #

  #DEV_FILE=/dev/sdc
  DEV_FILE=$HOME/test_backend/test.img

  # For iSCSI, the iqn name seems to correspond to the NAA name.
  NAA_STR=iqn.2003-01.org.linux-iscsi.target.x8664:sn.5e47974d8c71
  VPD_STR=b9802841-1d9a-4e08-a8a0-d4161221

  mkdir -p /sys/kernel/config/target/core/tcmu_0/test

  # This contains an address from a running program---that's fine, since it's the
  # directory structure in /config I'm interested in.  If I got the user space target
  # as far as tripping over the bad pointer, I'd be pretty happy right now.
  #
  echo -n mailbox_addr=139752828575744,mailbox_size=18948096,dev_size=43275 >\
                                  /sys/kernel/config/target/core/tcmu_0/test/control

  echo $DEV_FILE >/sys/kernel/config/target/core/tcmu_0/test/udev_path

  echo 1 >/sys/kernel/config/target/core/tcmu_0/test/enable

  echo $VPD_STR >/sys/kernel/config/target/core/tcmu_0/test/wwn/vpd_unit_serial

  ln -s /sys/kernel/config/target/core/tcmu_0/test \
  /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.target.x8664:sn.5e47974d8c71\
  /tpgt_1/lun/lun_0/aaaaaaaaaa

  echo return value from ln: $?

As I understand it, from reading the source of the targetcli tool which sets these things up, this script would be the way to do this by hand.  Set up the structure under /sys/kernel/config/target/iscsi (this is done automatically on my VM, after I set it up in targetcli and did a saveconfig); set up the structure in /sys/kernel/config/target/core (the new user space target, which I confirmed to be active by noting that the pseudo-directories I make are getting populated); set up soft links between the two pseudo-directories to indicate that the one connects to the other.  However, the $? from the ln returns an error, and the new link under lun_0 is not being made.  That I’m connecting the backend to a file, rather than a raw device as I’d like, isn’t even the issue yet, as I’m not making even that connection.

Ultimately, I would like to connect to the user space backend through iSCSI, using a raw block device as a backing store, and run some benchmarking through it, varying any parameter I can think of to see which will and will not make a difference.  Then I could compare with benchmarking on SCST user space and LIO talking to a raw device, which I’ve already done, and see how this thing compares.  Suggestions?

Many thanks in advance!
This message contains confidential information. If you are not the intended recipient you are hereby notified that disclosing,copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140213/ce9fe864/attachment.html