[Stgt-devel] Errors in fsck with iSER (was: iSER patches, third release)

[Erez Zilber]

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