Jan-Piet Mens

While copying some biggish files onto a TrueCrypt volume, I was keeping an eye out for the CPU load, after upgrading to a new version.

This view greatly surprised me:

An X11 server running consuming 100% of a CPU? WTF? It turns out that there was another top process running on the X server, and its output caused the server to suddenly utilize 100% CPU. Just hiding the top (not quitting top) window immediately brought resources back down to normal.

The morale of the story? Watch what you leave unseen.

The Open Source FreeNAS server is a NAS server which supports a large number protocols with which users can access files (OpenFiler is a similar project based on Linux). Those wishing to have a peek at FreeNAS without sacrificing a PC can do so with the VMware image supplied by the project.

A newer addition to the software is an iSCSI target which can be used to test iSCSI initiators.

After installing FreeNAS on a spare machine I created added a couple of iSCSI targets on it, which resulted in a configuration like this one:

Targets are created as container files of the size specified when adding them, and if you've enabled SSH access to the appliance, you can see the container file on the file system it is mounted on, after logging in.

On a CentOS 4 machine, I added the necessary software built from the Linux iSCSI Project with a

# yum install iscsi-initiator-utils

and then configured the initiator to access my FreeNAS target.

# grep -v '^#' /etc/iscsi.conf
DiscoveryAddress=192.168.1.180

After starting the iscsi service, the kernel messages on my server reported:

iscsi-sfnet: Loading iscsi_sfnet version 4:0.1.11-3
iscsi-sfnet: Control device major number 254
iscsi-sfnet:host6: Session established
scsi6 : SFNet iSCSI driver
iscsi-sfnet:host5: Session established
scsi5 : SFNet iSCSI driver
  Vendor: NetBSD    Model: NetBSD iSCSI      Rev: 0
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: NetBSD    Model: NetBSD iSCSI      Rev: 0
  Type:   Direct-Access                      ANSI SCSI revision: 03
SCSI device sdc: 204800 512-byte hdwr sectors (105 MB)
SCSI device sdc: drive cache: write through
SCSI device sdc: 204800 512-byte hdwr sectors (105 MB)
SCSI device sdc: drive cache: write through
 sdc: unknown partition table
Attached scsi disk sdc at scsi5, channel 0, id 0, lun 0
SCSI device sde: 1024000 512-byte hdwr sectors (524 MB)
SCSI device sde: drive cache: write through
SCSI device sde: 1024000 512-byte hdwr sectors (524 MB)
SCSI device sde: drive cache: write through
 sde: unknown partition table
Attached scsi disk sde at scsi6, channel 0, id 0, lun 0

I then created a partition on one of the new disks with a fdisk /dev/sdc and, after creating a file system on that, I could mount and start using the remote disk. It is quite that simple.

If you intend using the initiator or target on a SLES 9 machine, there is a good description of how that is done here, and this one is for Fedora Core 4.

For Windows, Nimbus have an iSCSI Target for Windows which might also be of interest, as apparently

anyone can create an IP SAN in seconds using their existing server and storage hardware. MySAN works by turning any Windows partition (such as a hard drive, internal RAID array, external storage system, or even Fibre Channel storage) into an iSCSI target

I can't vouch for that, but it sounds interesting.

As far as initiators are concerned, Microsoft has one which can be downloaded from the iSCSI Software Initiator page. I tried it and it successfully attached my sample iSCSI target to a Windows XP client machine.

This is all good stuff. Now I just need a small iSCSI capable appliance. Any suggestions?

Thanks, Britta.

photo: Roberto Roseano.

The 1st International Conference on LDAPv3 has issued a Call for Papers.

The conference will be held on September 6th and 7th in Köln, Germany.

We are in the process of setting up a demo environment which will simulate the deployment of the Novell Open Workgroup Suite over two distinct geographical regions, in order to get a better grasp of the components that make up the suite, and how they interact during situations of connectivity loss.

Two main components need special consideration: eDirectory and NSS, the Novell Storage Services, and we still have many a question regarding the latter.