April

Inzwischen liefert mir mein Provider natives IPv6. Und natürlich hängt der Anschluss an einer C10k, die solche Pakete unter bestimmten Umständen schrotten indem sie versuchen die Länge aus dem IP-Frame zu lesen.

The linux kernel includes a SCSI target infrastructure since 2.6.20. Most of the code is located in the userspace and supports iSCSI, ibm i/pSeries virtual SCSI and Xen SCSIback.

To work properly it needs a bunch of patches on top of 2.6.21-rc.

After I got it working I did some tests with bonnie. First the target:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           32124  17 18063   6           45815   4 324.6   0

Now with the vSCSI initiator:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           18513   9 16208   5           34003   3 221.4   0

And the iSCSI initiator:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           31631  14 12809   4           39241   5 306.3   1

As this tests was done on one OpenPower machine, all transfers uses DMA between the two systems.

The vscsi case is currently limited to 128KiB per request, maybe this is a problem.

Nein, man sollte sich nicht wundern, dass das System sich so träge anfühlt, wenn /proc/mdstat folgendes zeigt:

md0 : active raid5 sdb[0] sdd[2] sdc[1]
      67108608 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]
      [==========>..........]  resync = 53.2% (17870972/33554304) finish=7.3min speed=35319K/sec

It happened again. The linux-2.6 2.6.20-1 release failed for arches which we don't build snapshots for. This means that none of them was ever built in the time after I commited the whole stuff.

As this happens over and over again I consider this a real problem now. So the following arches needs new debian-kernel maintainers: alpha, hppa, and mips.

I thought the problems with pvmove was fixed with devmapper 1.02.12, but I just run into this problem again. Not sure if there was different fixes in later versions.

pvmove suspends the devices and fails to reload tables under some conditions. This time it just blocked while the devices for /usr und /var was suspended. This means the system is dead.

Update: It seems to be related to the number of LVs to move. Only one works all the time.