[stgt] mkfs problem

[charles zhuang]

Hi,
I have used the NetBSD iscsi target code base and add the iser layer to it for my project, same as STGT, all the code are in user space. The NetBSD architecture is simpler than STGT, all operation is single entry run from the top to all the way down to disk read/write. 
I have encountered a problem that has stuck me for 2 weeks and I will like to see if anyone on this board can provide me some tips.
My code works fine on a backstore file size at 5, 10, 15MB, but when I use 8MB backstore file, tcp (the original code) is fine, rdma code has problems.
In rdma case, I run thru login, fdisk to create a new partition, mkfs.ext3 to create the ext3 file system, then mount. The mount fail and complain "mount: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or other error".
I use strace on mkfs and mount, in both tcp and rdma case, they all write to the same location for superblock, all write and read return correct size, no program trace error has reported. I also create a test program to write and read back from the same location from the initiator by directly use open/read/write call, use same offset as indicated by strace, no problem. The backstore, disk function, and scsi layer are shared by both tcp and rdma, only the transport layer where the tcp send/recv are replaced by the rdma send/read/write code.
Looks like in rdma code path, the mkfs will corrupt some data in backstore, while tcp code is fine. If I copy over the backstore file that tcp code has done on mkfs, the rdma code can mount thru that and run charmingly. 
I don't think my rdma code cause the problem, as it just transfer data and works perfectly for other virtual disk size (5, 10, 15 MB, I haven't tried any bigger size yet). I suspect different backstore disk size will trigger mkfs behave differently but I can't explain why the tcp path works.
I have spent 2 weeks already trying to figure out what's wrong with the mkfs issue, but still fruitless. 

Does anyone here have a better way to debug this issue, i.e., figure out what mount is explaining about and trace back to the virtual disk file.

Thanks very much for any help.

 Thanks,
Charles


      
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html