Drobo

DroboApp announcement: stgt-1.0.23

A new version of the iSCSI target server is out, so I decided to take another look and try to fix some of the issues discovered in the previous version 1.

You can find it here: http://www.droboports.com/app-repository/stgt-1-0-23

Here’s a short changelog:
[list]
[]service.sh has been fixed to properly start, stop and restart the server. Thanks to bujam1 for the help getting this one right (fingers crossed).
[
]targets.conf will not be replaced during an upgrade (hopefully). I still advise backing up your “etc” folder.
[*]tgt-admin has been completely changed. It has been hardcoded to work with the perl DroboApp from DroboPorts, and it has been wrapped around a shell script that sets up the perl environment correctly. In other words, tgt-admin should work seamlessly.
[/list]
As usual, comments, suggestions and feedback are welcome.

FYI, Initial indications are that this package is working perfectly! For Windows users I could recommend this as an easy way to have iSCSI to the DroboFS; Mac users it’s a bit of a harder sell due to the lack of a free initiator.

Is there any way to use a sparse file as the backing for iSCSI target? It would certainly make it more feasible to use large volumes.

Good to hear!

For the sparse file, you can try something like this 1:

dd if=/dev/zero of=/path/to/the/iscsi-file bs=1 count=0 seek=8G

This will create an 8 GB sparse file.

By the way, should stgt be consuming memory like this - even when it’s been completely idle and unused?

__PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND 14909 1 root S 266m143.8 0 0.0 /mnt/DroboFS/Shares/DroboApps/stgt/sbin/tgtd

I noticed my DroboFS churning madly today, and finally ssh’ed in to see what it was chewing on. All I can assume is it’s been swapping - sadly I didn’t note the memory usage numbers before stopping the stgt service. Log is completely empty - not even startup/shutdown messages in it (which makes me wonder if logging is functional).[hr]

That worked like a charm! I’d update the instructions to use that variant of dd - it makes this infinitely more useful. I’d go so far as to say this is ready for the “masses”. :slight_smile:

Yup, I noticed this as well. It is really a shame that the FS has so little memory. If we had at least 512 MB this little box would be a beast.

I wonder how hard it is to mod the FS to replace the memory chips with a higher capacity version… they’re probably surface mounted, but I wonder how expensive it is to have someone replace them. Something like this: http://www.youtube.com/watch?v=0EUAEtri3h0 </devious idea>

Weird. My log file has some startup and shutdown messages. Maybe a write permission problem on the var folder?

Nice to hear! I’ll update the page to use the sparse file instead.

I just finished updating the page, but I came up with an idea for this DroboApp.

Since sparse files basically take no space as long as there is nothing inside, I could modify the DroboApp to automatically create the sparse files if there is no configuration in place already.

The automatically generated configuration would be 8x 2TB sparse files, since iSCSI can only expose 2TB at a time, and 16TB covers all the thin-provisioning space of the DroboFS. Each one of these files would be exposed as a different volume. Then, at the client side, people would be able to span them together in a single logical volume.

What do you think?

Seems like a reasonable default configuration. However, anyone using this port will have to get to know the details of iSCSI targets and such to mount it, so I don’t know how much friendlier it makes it in the end. Also, you’d have to make a determination on where the sparse files are located, and different folks are likely to want them in different spots (home directory outside of the shares, contained on DroboApps, on another share for backup - etc).

Uh-oh - ran into one potential show stopper with sparse files today. Busybox “cp” doesn’t recognize them and expands them to full size on copy. I wondered why an extra light had appeared on the Drobo, and found it was trying to create a nice new 2TB file - zeros and all.

Have you tried to use --sparse=always ?

Edit: nevermind me, I forgot that the FS has busybox instead of the normal cp command.

New version is out: http://www.drobospace.com/forums/showthread.php?tid=8174

I am having problems getting it to work, the log file says:

Can’t locate strict.pm in @INC (@INC contains: /mnt/DroboFS/Shares/DroboApps/stgt/lib/perl5/site_perl /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /mnt/DroboFS/Shares/DroboApps/stgt/sbin/tgt-admin.pl line 9.
BEGIN failed–compilation aborted at /mnt/DroboFS/Shares/DroboApps/stgt/sbin/tgt-admin.pl line 9.

Any ideas?

Have you tried the latest version?

Oh sorry, I’m on the latest version (didn’t realize that the thread was version specific).

grep version /mnt/DroboFS/Shares/DroboApps/stgt/service.sh

version=“1.0.24”[hr]
Now it works, upgraded Perl to the latest version (5.14) and ta-da! Great work, thanks!

Yeah, I try to make a new one for each release, so that people installing the latest version don’t get swamped in comments about the previous versions.

In any case, try to replace the content of sbin/tgt-admin with this:

[code]#!/bin/sh

sbin_dir=dirname \realpath $0`prog_dir=dirname ${sbin_dir}`
perl_inc=/mnt/DroboFS/Shares/DroboApps/perl/lib

export PATH="${sbin_dir}:$PATH"
export PERL5LIB=${prog_dir}/lib/perl5/site_perl:${perl_inc}/site_perl/5.14.0/none-linux-gnueabi:${perl_inc}/site_perl/5.14.0:${perl_inc}/5.14.0/none-linux-gnueabi:${perl_inc}/5.14.0
${sbin_dir}/tgt-admin.pl $@
[/code]
Note: “export PERL5LIB” and the paths after it should be on one line.