iscsi support
Dwight Hubbard
Squeeze chroot. Now that I have iscsi working I have one question.
Is it possible to use LVM instead of MD without overwriting the DLink
firmware?
I would imagine my performance would be better with a LV than running
on a file.
I.E will dlink's firmware have issues if I shrink /dev/sda2 and /dev/
sdb2 and create a new LVM partition on /dev/sda3 and /dev/sdb3 which
could be placed in a Volume group.
I imagine this wouldn't only benefit iscsi since it would make it
possible to have multiple mirrored/concat/striped and snapshot logical
volumes on the same disk(s).
Dwight Hubbard
an ipk package and I can now see/modify iscsi targets without using
the debian chroot environment.
Next question, is there any documentation on setting up and or
extending the web interface?
Joao Cardoso
On Jan 5, 9:05 am, Dwight Hubbard <dwight.hubb...@gmail.com> wrote:
> Just a quick note, I managed to build the scst iscsi target package as
> an ipk package and I can now see/modify iscsi targets without using
> the debian chroot environment.
HowToBuild and HowToCreatePackages wiki entries?
Do you mind sharing the relevant buidroot and ipkg configuration
files? I could add then to svn and offer the iscsi package to all
users. You would receive the deserved credits in the svn commit
message.
> Next question, is there any documentation on setting up and or
> extending the web interface?
entry.
Near the end you will find instructions on how to do it. (Starting and
stopping a service, Using the Services web pages, and Configuring the
service using a web page sections)
As an example of a simple and clean web administering web page, take a
look on the recent August Boot contribution to syslog: usr/www/cgi-bin/
syslog* and etc/init.d/S10syslog
Joao Cardoso
On Jan 4, 7:38 am, Dwight Hubbard <dwight.hubb...@gmail.com> wrote:
> I've been playing with iscsi in my DNS-323 running Alt-F and a Debian
> Squeeze chroot. Now that I have iscsi working I have one question.
>
> Is it possible to use LVM instead of MD without overwriting the DLink
> firmware?
permitting.
You can try to do it it and see the module size.
Just checkout 0.1B6, follow the HowToBuild wiki entry and do a clean
build.
Take a note on the size of the kernel and rootfs:
ls -l $BLDDIR/binaries/dns323/
After that, do
make O=$BLDDIR linux26-menuconfig
and check
device drivers -> Multiple devices driver support (RAID and LVM) -
>Device mapper support
then to a new build (make O=$BLDDIR) and note the size increase in the
kernel and rootfs
Including user-space package support in the firmware will certainly be
a problem, but it can always be done as disk-installable package
(netatalk follows the same principle, there is builtin kernel support
and the user-space programs are offered as a package -- not working at
the moment)
> I would imagine my performance would be better with a LV than running
> on a file.
>
> I.E will dlink's firmware have issues if I shrink /dev/sda2 and /dev/
> sdb2 and create a new LVM partition on /dev/sda3 and /dev/sdb3 which
> could be placed in a Volume group.
Dwight Hubbard
I built the device mapper modules last night but haven't had time to see if they actually work.
--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To post to this group, send email to al...@googlegroups.com.
To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/alt-f?hl=en.
Dwight Hubbard
damn dlink firmware still gives me the prompt to repartition the disk
though, even though I copied over the .systemfile directory from my
reference drive. Evidently it is doing more than just checking for
the directory.
Dwight Hubbard
some time.
Dwight Hubbard
At this point I have working LVM, iSCSI, and AoE (vblade) using
manually installed kernel modules for alt-f and a debian squeeze
chroot environment. So I know the stuff works on my DNS-323 and the
current alt-f environment.
I'm going to package up the lvm modules and debian into ipk files
(hopefully tonight assuming my wife doesn't have other plans for me)
After that I intend to see about building a native alt-f lvm package.
Ideally I'd want the package to be able to add an lvm configuration to
the disk wizard in the web interface. Any idea the best way to handle
the changes without stepping on the existing scripts?
Then I might take a look at getting the web interface for iSCSI/AoE
written. If I have time I will take another look at getting scsi-
target-utils working under ulibc.
Joao Cardoso
On Jan 7, 10:07 pm, Dwight Hubbard <dwight.hubb...@gmail.com> wrote:
> Ok, where do I send the packages to?
binary packages.
I was expecting you to send the buildroot and ipkg configuration files
and the kernel config diff. Then I would svn commit them, create the
package by myself and made it available.
Packaging should be done on a package by package basis. i.e., if for
your work you need package a that needs package b, two sets of
configuration files are needed, stating that package a needs package
b.
If you write some web pages (not mandatory), or an initscript, they
should be included in the top-most package file list.
> At this point I have working LVM, iSCSI, and AoE (vblade) using
> manually installed kernel modules for alt-f and a debian squeeze
> chroot environment. So I know the stuff works on my DNS-323 and the
> current alt-f environment.
chroot environment? If yes, they are not candidates for Alt-F.
Unless you write a package that when installed does all that is needed
to created the chroot environment :-)
You see, with Alt-F I don't want users to type commands or follow
instructions on how to run or configure a program; for that we already
have Debian.
This does not means that all packages must have a configuration web
page. Some don't need them, but if they provide a end-user
configurable service, they must. Even if only providing the most
simple (and most common) configuration setup.
Of course a package undergoes improvements over time, and at first
they don't need to have the web pages, but at least an initscript is
needed.
> After that I intend to see about building a native alt-f lvm package.
> Ideally I'd want the package to be able to add an lvm configuration to
> the disk wizard in the web interface. Any idea the best way to handle
> the changes without stepping on the existing scripts?
And it does not make many sense, because for adding the new options
you would need an already configured disk setup where to store the
packages, which is the wizard task itself -- kind of egg-chicken
problem.
Dwight Hubbard
as an alt-f package. The package is fairly large (obviously) and
still highly experimental (I had an issue with the remove scripts
blowing away part of the alt-f environment, bind mounts are a pain
when they don't unmount correctly). But it does work on my dns-323.
To install I added my unstable ipkg repo (http://ipkg.dhub.me/
unstable) from the web interface and refreshed the package list and I
can then install the debian chroot environment.
Also, I can set up/unset up the chroot environment from the system
services menu of the web interface.
The package does not use the alt-f build tools because the ipkg build
scripts didn't handle some of the file types in the debian chroot
image properly. The source for the debian package is at:
http://ipkg.dhub.me/source/debian_squeeze_1.0.0_src.tar.gz
The package includes a few commands:
/usr/bin/deb - Provides a bash shell in the debian chroot environment
/usr/bin/apt-get - Runs apt-get commands in the debian chroot
environment
/usr/bin/aptitude - Runs aptitude commands in the debian chroot
environment
So for example to set up an iscsi target:
1. I log into the dns-323 via ssh
2. Install the debian iscsi target
aptitude install tgt
3. Create a directory for the backing files for my iscsi devices
mkdir /mnt/sda2/iscsitargets
4. Switch into the chroot environment to configure the iscsi target
deb
5. Create an iscsi backing file
tgtimg --op new --device-type disk --type disk --size 1024 --file /
mnt/sda2/iscsitargets/iscsitarget0
6. Start the tgtd service (iscsi target)
tgtd
7. Create an iscsi target
tgtadm --mode target --op new --tid 1 -T iqn.
2011-01.com.example:iscsi0
8. Add the iscsi image from step 5 as an iscsi lun of the target
created in step 7
tgtadm --op new --mode logicalunit --tid 1 --lun 1 -b /mnt/sda2/
iscsitargets/iscsitarget0
9 Allow the target to accept connections (this allows connections
from everywhere so it's very unsecure)
tgtadm --op bind --mode target --tid 1 -I ALL
10. Exit the chroot environment
exit
Oh, and yes the target can be accessed by an external host:
# iscsiadm --mode discovery --type sendtargets --portal 192.168.1.5
192.168.1.5:3260,1 iqn.2011-01.com.example:iscsi0
# iscsiadm --mode node --targetname iqn.2011-01.com.example:iscsi0 --
portal 192.168.1.5:3260 --
login
Logging in to [iface: default, target: iqn.2011-01.com.example:iscsi0,
portal:
192.168.1.5,3260]
Login to [iface: default, target: iqn.2011-01.com.example:iscsi0,
portal: 192.168.1.5,3260]:
successful
# dmesg | tail -1
[94286.634115] sd 6:0:0:1: [sdf] Attached SCSI disk
# hdparm -t /dev/sdf
/dev/sdf:
Timing buffered disk reads: 34 MB in 3.09 seconds = 11.01 MB/sec
Next build an alt-f package to do the configuration.
Joao Cardoso
> Ok, I have a package that sets up a debian squeeze chroot environment
> as an alt-f package. The package is fairly large (obviously) and
> still highly experimental (I had an issue with the remove scripts
> blowing away part of the alt-f environment, bind mounts are a pain
> when they don't unmount correctly). But it does work on my dns-323.
Excelent!
Have you read the HowToFixOrCustomizeFirmware wiki entry?
http://code.google.com/p/alt-f/wiki/HowToFixOrCustomizeFirmware
aufs might be a pain! There is au aufs.sh utility to handle the most common
operations.
...
> The package does not use the alt-f build tools because the ipkg build
> scripts
> didn't handle some of the file types in the debian chroot
> image properly.
You mean the mkpkg.sh script? Can you elaborate, please?
Thanks.
Dwight Hubbard
scripts so the debian service can be started/stoped (mounts/unmounts
the bind mounts in the chroot and sets up stuff like /etc/resolv.conf
and /etc/mtab in the chroot env)
However, mkpkg.sh didn't like the fact that the debian chroot image
has symlinks not pointing to files (they point to valid files if
you're in the chroot). It wouldn't build even if I used the force
flag.
Dwight Hubbard
with a md0 raid and found an error in the start script, I also changed
the uninstall script to hopefully fix the uninstall issue.
I put the source at: http://ipkg.dhub.me/source/debian_squeeze_1.0.4_src.tar.gz
The sources require the ipk file at: http://ipkg.dhub.me/unstable/debian_squeeze_1.0.4.ipk
since it doesn't make sense to put the complete debian chroot in the
source archive.
Dwight Hubbard
on the debian package I built.
The debian-iscsi package sets up iscsi in a debian chroot along with
the cgi scripts to allow it to be configured in the alt-f services web
interface.
I've been installing the package for testing from my unstable feed at
http://ipkg.dhub.me/unstable
These are disk only install packages which almost certainly will keep
the disk from being able to sleep. Since, My current alt-f tree
required a good number of changes to get these packages built. I'd be
happy to try and clean them up a bit (hopefully eliminating most of
the changes) to include upstream. However, I would certainly
understand if Joao doesn't feel they should be included in the tree
since the aren't designed for a flashable distro.
Dwight Hubbard
Currently in the web interface it isn't possible to configure access
controls so the configured iscsi targets can be accessed by any host
on the network. I hope to have this working in the next version
On Jan 18, 8:54 am, Dwight Hubbard <dwight.hubb...@gmail.com> wrote:
> I added another package called debian-iscsi, this package is dependent
> on the debian package I built.
>
> The debian-iscsi package sets up iscsi in a debian chroot along with
> the cgi scripts to allow it to be configured in the alt-f services web
> interface.
>
Joao Cardoso
> I added another package called debian-iscsi, this package is dependent
> on the debian package I built.
...
> Since, My current alt-f tree
> required a good number of changes to get these packages built. I'd be
> happy to try and clean them up a bit (hopefully eliminating most of
> the changes) to include upstream. However, I would certainly
> understand if Joao doesn't feel they should be included in the tree
> since the aren't designed for a flashable distro.
I appreciate your efforts, thanks.
Please send your diff from the current tree, no need to clean it up. I will
give it a glimpse and ask for the cleanup if merging makes sense.
Not all changes/submissions has to be for the base firmware, Alt-F also has
disk-installable packages.
You will find the configuration file in the .config-pkgs file at the root at
the tree, just move .config-pkgs to .config and do a make ... menuconfig. I
often create a new build root for packages only.
I downloaded your first announced packages, but the huge size discouraged me.
The src package had almost nothing, if I remember correctly.
Is it possible to download the chroot binary from a well know debian site,
using the pre/postinstall package script?
I explain: I had in the past thinking in providing meta-packages, without
almost no content. The pre or postinstall script would do the download of the
real package from the package feed and install it.
An untested example to of postinstall script from an hypothetical Alt-F
package named subversion-1.5.2-1.ipkg:
wget http://www.inreto.de/dns323/fun-plug/0.5/packages/subversion-1.5.2-1.tgz
\
-o tmp/subversion-1.5.2-1.tgz
funpkg -i tmp/subversion-1.5.2-1.tgz
-------------------------------------------------------------------------------------------------------
A related question for you, which seems to be an experienced debian person:
You might also read my experiments with Squeeze:
http://forum.dsmg600.info/viewtopic.php?pid=38452#p38452
The relevant part:
> I kexec a recent (spliced) netboot.img from a running Alt-F kernel, no
> flashing involved. Once booted, the netboot kernel worked at 1000 but not
> at 100mbps (*) -- I continued the installation at 1gbps. Near the
> installation end, the installer flashed a new kernel (2.6.32-23) and
> performed a reboot. After reboot 2.6.32-23 worked at both speeds.
> So I kexec a Alt-F kernel (built without CONFIG_MARVELL_PHY) from within
> squeeze, and it worked also at both speeds. Then I flashed the new Alt-F
> kernel, and after a reboot is works at both speeds.
>
> As a side effect of all this, I now have squeeze installed on a disk, and I
> can kexec it from within Alt-F! Nice. I now have debian as an Alt-F
> "package" smile
>
> Does any debian user knows how can one disable the flash installation step
> of the installer? That would allow me to automated the installation of
> debian only on disk, and allow users to run it from within Alt-F without
> extra flashing.
The last paragraph is the key one: do you know how can one avoid the final
debian flashing?
Dwight Hubbard
> I downloaded your first announced packages, but the huge size discouraged me.
I could probably build a smaller package if I remove things like docs and man pages. I didn't because I figured some people would want them.
> The src package had almost nothing, if I remember correctly.
That's correct it doesn't include the chroot tree. Just the scripts and configs to build the .ipk
> Is it possible to download the chroot binary from a well know debian site,
> using the pre/postinstall package script?
Not that I can think of, the file contains a base Debian squeeze root filesystem that I cross compiled using the debian tools. As far as I know there aren't images like that on the debian servers just the debbootstrap scripts to generate them.
Further stuff is installed from the normal Debian repositories though.
> I explain: I had in the past thinking in providing meta-packages, without
> almost no content. The pre or postinstall script would do the download of the
> real package from the package feed and install it.
> An untested example to of postinstall script from an hypothetical Alt-F
> package named subversion-1.5.2-1.ipkg:
The debian-iscsi package is essentially that, the preinst script does the apt-get in the chroot environment of the necessary packages and installs /etc/init.d/debian.iscsi start script and several .cgi scripts in /usr/www/cgi-bin for the web interface. So the whole package is really nothing but scripts.
It's really easy to build a package like this for stuff that has a web interface. I have a fairly generic start script that calls the start script in the chroot and a cgi template that runs the web interface in an iframe. I got sabnzbdplus running this way this morning.
I need to automate the build process though.
> -------------------------------------------------------------------------------------------------------
> A related question for you, which seems to be an experienced debian person:
>
> You might also read my experiments with Squeeze:
> http://forum.dsmg600.info/viewtopic.php?pid=38452#p38452
I'll have to take a look if I get more time. I was already wondering how hard it would be to get the alt-f fun-plug to use the kernel from the debian chroot, since if that worked I wouldn't have to compile and build alt-f specific kernel modules for things like the device mapper and drbd.
I find it odd that you were noticing network issues with the various kernel versions since during my iSCSI testing it was pretty obvious the network was the bottleneck (hdparm -t /dev/sda when run from a shell on the dns-323 gives me 37MB/s, if I export an iSCSI lun from that disk and run hdparm -t on it I see about 15MB/s, this is to a host connected via a cat-6 cable directly to the DNS-323 for the test, so it appears there is either a driver or hardware issue with the Nic causing the poor performance)
Joao Cardoso
...
> I'll have to take a look if I get more time. I was already wondering how
> hard it would be to get the alt-f fun-plug to use the kernel from the
> debian chroot,
I don't see any reason why you couldn't do that. Have you tried?
As a matter of fact I don't understand your motivation on using Alt-F to
chroot debian...
> since if that worked I wouldn't have to compile and build
> alt-f specific kernel modules for things like the device mapper and drbd.
As I told earlier, I intend to make a kernel-modules disk-installable package.
Just post those you need. Although I can't promise when I will do it.
> I find it odd that you were noticing network issues with the various kernel
> versions since during my iSCSI testing it was pretty obvious the network
> was the bottleneck (hdparm -t /dev/sda when run from a shell on the
> dns-323 gives me 37MB/s, if I export an iSCSI lun from that disk and run
> hdparm -t on it I see about 15MB/s, this is to a host connected via a
> cat-6 cable directly to the DNS-323 for the test, so it appears there is
> either a driver or hardware issue with the Nic causing the poor
> performance)
I noticed a degraded network transfer speed (sustained) since earlier Alt-F
releases. Don't know why, and Alt-F really needs tuning in some aspects.
Since the appearance of multi-cores/GHz/GB PCs, performance tuning is becoming
a lost art :-)
For iSCSI you might benefit from using a greater MTU, at least the size of a
page. Never used, speculating.
I use to compare the DNS-323 Soc performance to an old P3@500MHz I had.
That is the reasons why I think that the cpu will not be able to handle the
many software layers needed by some protocols.
I remember setting up raid-0 on the old P3 and see no performance improvement
over using a single standard disk.
The following ad-hoc tests shows that there is some room to play with, but not
too much:
http://groups.google.com/group/alt-f/browse_frm/thread/6165b89e775f6ead#
Dwight Hubbard
> > hard it would be to get the alt-f fun-plug to use the kernel from the
> > debian chroot,
>
> I don't see any reason why you couldn't do that. Have you tried?
unfortunately the box never came back up on the network with the new
kernel and initrd and since I don't have a serial port troubleshooting
is basically trial and error. It is also slow since I do a lot of my
work on transit while going to/from work and I obviously can't power
cycle the unit from the train. I should probably just fix that.
> As a matter of fact I don't understand your motivation on using Alt-F to
> chroot debian...
create packages that aren't easy to build/port to ulibc/busybox.
I also like having a simple web interface and no need to overwrite the
vendor flash.
> > since if that worked I wouldn't have to compile and build
> > alt-f specific kernel modules for things like the device mapper and drbd.
>
> As I told earlier, I intend to make a kernel-modules disk-installable package.
> Just post those you need. Although I can't promise when I will do it.
issues where the userspace and kernel aren't compatible.
Ideally I'd like to be able to run stuff like OpenNAS under the chroot
but when I run it currently the only useful thing the web interface
does is displays the box's status. All the cool stuff requires kernel
support.
> > I find it odd that you were noticing network issues with the various kernel
> > versions since during my iSCSI testing it was pretty obvious the network
> > was the bottleneck (hdparm -t /dev/sda when run from a shell on the
> > dns-323 gives me 37MB/s, if I export an iSCSI lun from that disk and run
> > hdparm -t on it I see about 15MB/s, this is to a host connected via a
> > cat-6 cable directly to the DNS-323 for the test, so it appears there is
> > either a driver or hardware issue with the Nic causing the poor
> > performance)
>
> I noticed a degraded network transfer speed (sustained) since earlier Alt-F
> releases. Don't know why, and Alt-F really needs tuning in some aspects.
> Since the appearance of multi-cores/GHz/GB PCs, performance tuning is becoming
> a lost art :-)
performance as well. I just hope the issue isn't the actual hardware.
> For iSCSI you might benefit from using a greater MTU, at least the size of a
> page. Never used, speculating.
even worse using the default MTU. I see similar speeds using iperf so
I'm guessing the issue is the kernel driver or the onboard GB hardware
can't really do full GB ethernet speed.