FUJITA Tomonori wrote: > On Mon, 10 Dec 2007 10:03:25 -0500 > Pete Wyckoff <pw at osc.edu> wrote: > > >> This is the third major release of support for iSCSI Extensions >> for RDMA (iSER) to the existing TGT user space SCSI target. It >> uses OpenFabrics libraries and kernel drivers to act as a SCSI >> target over RDMA-capable devices. The code has been tested >> against the existing Linux iSER initiator over InfiniBand cards, >> but should be specification compliant and work generally. >> >> A bit of documentation is included, and a short technical report is >> available at http://www.osc.edu/~pw/papers/iser-snapi07.pdf with >> slides from a presentation at >> http://www.osc.edu/~pw/papers/wyckoff-iser-snapi07-talk.pdf . >> >> The iSER patches can be downloaded from: >> >> git://git.osc.edu/tgt >> >> or browsed at: >> >> http://git.osc.edu/?p=tgt.git;a=summary >> >> Changes since previous series are as follows. >> > > I merged all the patches. Now mainline tgt supports iSER. Thanks! > > I also applied some patches that could break iSER support. iSER > people, please test the latest tree. > We ran some tests on it. Most of them are ok except for fsck. We ran it in the following way: seed5:/tmp/regtest # parted -s /dev/sdb mkpart primary 0 8500 seed5:/tmp/regtest # for ((i=1;i<=1000;i++)) do mkfs -t ext2 -q /dev/sdb1; fsck -y -ft ext2 /dev/sdb1; echo iteration $i is done; done fsck is ok most of the time, but once in a while it looks like this (after ~300 iterations): fsck 1.38 (30-Jun-2005) e2fsck 1.38 (30-Jun-2005) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdb1: 11/1038336 files (0.0% non-contiguous), 32599/2075195 blocks seed5:/tmp/regtest # mkfs -t ext2 -q /dev/sdb1 seed5:/tmp/regtest # fsck -y -ft ext2 /dev/sdb1 fsck 1.38 (30-Jun-2005) e2fsck 1.38 (30-Jun-2005) Pass 1: Checking inodes, blocks, and sizes Inode 340497 is in use, but has dtime set. Fix? yes Inode 340497 has imagic flag set. Clear? yes Inode 340498 is in use, but has dtime set. Fix? yes Inode 340498 has imagic flag set. Clear? yes Inode 340499 is in use, but has dtime set. Fix? yes Inode 340499 has imagic flag set. Clear? yes Inode 340500 is in use, but has dtime set. Fix? yes Inode 340500 has imagic flag set. Clear? yes Inode 340501 is in use, but has dtime set. Fix? yes Inode 340501 has imagic flag set. Clear? yes Inode 340502 is in use, but has dtime set. Fix? yes Inode 340502 has imagic flag set. Clear? yes Inode 340503 is in use, but has dtime set. Fix? yes Inode 340503 has imagic flag set. Clear? yes Inode 340504 is in use, but has dtime set. Fix? yes Inode 340504 has imagic flag set. Clear? yes Inode 340505 is in use, but has dtime set. Fix? yes Inode 340505 has imagic flag set. Clear? yes Inode 340506 is in use, but has dtime set. Fix? yes Inode 340506 has imagic flag set. Clear? yes Inode 340507 is in use, but has dtime set. Fix? yes Inode 340507 has imagic flag set. Clear? yes ... BTW - we ran the same test directly from the target (i.e. on iSCSI involved) and it was ok, so I don't think that we can blame the actual storage. Erez |