How to grow an iSCSI-presented zvol in 3 easy steps

Well, ok, it's not quite 3 easy steps.

A couple of things that don't work: iscsitadm modify target -z . This only works if the iscsi target's backing store is a regular file, which in the case of a zvol, it is not.

The easy bit: Make the zvol bigger:
zfs set volsize=200G tank/iscsi/thevol

Now we have to hack around in the iscsi parameters file: Locate the /etc/iscsi/tgt//params.# file that corresponds to the right target and lun and change the <size> parameter to be the new (in hex) size of the bigger volume in 512-byte blocks. Or in other words,
zfs get -Hp volsize tank/iscsi/thevol | perl -lane 'printf("%llx", $F[2]/512)'


Once that's done, apparently you have to bounce the iscsitgtd to get it to reread the params file.

Then on to the initiator...

format c3tAREALLYLONGSTRINGOFDIGITSFORTHEDISKGUIDd0s0 and changing the parameters won't work, since I'm using EFI labels and it says very strongly
partition> label
Unable to get current partition map.
Cannot label disk while it has mounted partitions.


So I have to go in the other way. While I'm in format, print out the current partition table, and make note of the Last Sectors for the slices. Also, run prtvtoc against the disk to get any other useful bits.

Then I can make the actual partition changes with fmthard:
fmthard -s - /dev/rdsk/c3tAREALLYLONGSTRINGOFDIGITSFORTHEDISKGUIDd0s0

At first, just copy in the line(s) for the slices you already have, but move slice 8 to the end of the disk:
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 34 251641754 251641787 /zones/mars/data
8 11 00 419413982 16384 419430365


Then (check it in format to make sure the disk is still healthy) change the Last sector and sector count for the real partition. (Last is s8's first -1, and the sector count is s8's first -34)

Then it's a simple growfs -M /zones/mars/data /dev/rdsk/c3tAREALLYLONGSTRINGOFDIGITSFORTHEDISKGUIDd0s0

--Joe

Goodbye to a problem indicator

We have a new Sun T5220 with the new Niagara-II chip in it. I don't know if it's 8-core/8-thread or 4-core/16-thread but it shows up in Solaris as 16 CPUs.

I'm running a cpu-intensive process (bzip) and prstat is only showing it as using 1.2% of the CPU. On another older system, the same bzip takes up 25% of the 4-proc box.

On the old system, it's clear that bzip is a single-CPU bottleneck (because it's single-threaded). On the new one, well running full-out but only taking 1% doesn't look like much.

--Joe

Forcing kernel dump on Opensolaris x86

Just in case you were caught off guard by the documentation that points to using "rip::c" in mdb, that apparently doesn't work on Opensolaris, at least on build 70 that we have installed on our x4500s.

But on the bright side, I found a mention at wikia (http://opensolaris.wikia.com/wiki/Miscellaneous_FAQ) that says I should use $<systemdump. And that works.

Firewall + IPMP + IPF + Zones = lost packets

Blarg!

There's no intelligence in IPF to know where to send packets when IPMP detects a link failure.

So, even though the zone will get all the packets destined for it, the global kernel will pick an interface based on its global route table, pass the packet down the wrong interface, ipf will bounce it to the FAILED interface (below the ipmp layer, apparently) and the packet is never delivered.

So I need something that will notice when an IPMP failure occurs, and rewrites the IPF rules to respond to the networking topology change. Look for my PF_ROUTE socket watcher program to be posted shortly.

--Joe

Media server v0.1a

To solve the automation problem, I'll use Linux. Since I don't have any spare computers laying around any more (I'll turn in my geek card), I've gotta set it up in a VMware instance. Luckily, VMware server is free, and I have disk space here.

Two disks... 8GB for OS, and a 32GB "data" disk to start with. Both sparsely-allocated, cuz I don't have that much disk space.

I know debian better than any other distro. So, a base install, no tasksel, update and upgrade, then installed ssh, apache2, subversion, subversion-tools, and sudo. So far I'm using 515MB. And it can't do anything yet.

Someday I'd like to switch it over to Solaris so I can run the data under zfs, but for now, I like the convenience of aptitude.

In the mean time, it's LVM I guess... I pvcreate'd /dev/sdb, vgcreated dataVG /dev/sdb, and lvcreated dataLV in it. Then mke2fs -j /dev/mapper/dataVG/dataLV and tuned it to want a fsck every 365 mounts or 730d. Mounted it as /data, and I think I'm ready to start developing.

First some data, though... I grabbed about 350MB of data from various picture CDs, copied it to /data/media/$cdname, and copied them around again to make sure there were duplicates in the data...

More to come...