とりあえず、20100407版をvfs.zfs.vdev.max_pending=10で少し使用しています(Timeoutはそのまま)。今のところエラーは出ていません（といっても３０分ぐらいですが・・・）

ネットワークの設定については色々いじってますが、
現在FreeBSD 7.0 あたりからは自動的にTCPのバッファを調整する機能が実装さており、net.inet.tcp.sendspace,net.inet.tcp.recvspaceはほぼ使用していません。（あまりにもおかしいので勢いあまってOSのソースtcp_input.cとかを確認したので間違いないです)
現在は
net.inet.tcp.sendbuf_max
net.inet.tcp.recvbuf_max
等を使用するようです

この辺を参考にしました
http://fasterdata.es.net/TCP-tuning/FreeBSD.html

nsby 様
報告ありがとうございます。
前後のログがないのと、動作環境や設定が書かれてないので推測ですが、
ZFSの仮想ボリューム機能を使っていると、書込み処理が遅延しすぎて、
期待通りにいかない事があります。（既知の問題）
設定ファイルの Timeout 30 を倍の60にすると多少は効果あるかもしれません。
また、/boot/loader.confにvfs.zfs.vdev.max_pending=10を指定すると劇的に
改善される事を確認しています。

あと、ネットワークの設定を何も変更していないならば、
/etc/sysctl.confに以下のような設定も試す価値があると思います。
kern.ipc.maxsockbuf=1048576
net.inet.tcp.sendspace=393216
net.inet.tcp.recvspace=393216
net.inet.tcp.delayed_ack=0
これはiSCSIに限らずギガビット環境のチューニングになりますので、
他のサービスについても影響の有無を調べたほうが良いかもしれません。

負荷が高いと以下のようなメッセージが表示されます。
—
istgt_iscsi.c: 427:istgt_iscsi_read_pdu: ***ERROR*** iscsi_read() failed (errno=35)
istgt_iscsi.c:3614:istgt_iscsi_transfer_out: ***ERROR*** iscsi_read_pdu() failed
istgt_lu_disk.c:1735:istgt_lu_disk_transfer_data: ***ERROR*** iscsi_transfer_out()
istgt_lu_disk.c:3553:istgt_lu_disk_lbwrite: ***ERROR*** lu_disk_transfer_data() failed
istgt_lu_disk.c:5207:istgt_lu_disk_execute: ***ERROR*** lu_disk_lbwrite() failed
istgt_iscsi.c:3702:istgt_iscsi_transfer_out: ***ERROR*** task_tag(40006) error
istgt_lu_disk.c:1735:istgt_lu_disk_transfer_data: ***ERROR*** iscsi_transfer_out()
istgt_lu_disk.c:3553:istgt_lu_disk_lbwrite: ***ERROR*** lu_disk_transfer_data() failed
istgt_lu_disk.c:5207:istgt_lu_disk_execute: ***ERROR*** lu_disk_lbwrite() failed
istgt_iscsi.c:3897:istgt_iscsi_execute: ***ERROR*** got DATAOUT
istgt_iscsi.c:3904:istgt_iscsi_execute: ***ERROR*** unsupported opcode 5

とか

istgt_iscsi.c:3614:istgt_iscsi_transfer_out: ***ERROR*** iscsi_read_pdu() failed
istgt_lu_disk.c:1735:istgt_lu_disk_transfer_data: ***ERROR*** iscsi_transfer_out()
istgt_lu_disk.c:3553:istgt_lu_disk_lbwrite: ***ERROR*** lu_disk_transfer_data() failed
istgt_lu_disk.c:5207:istgt_lu_disk_execute: ***ERROR*** lu_disk_lbwrite() failed
—

errnoが35=EAGAINって事なので、適当にistgt_sock.cの
USE_POLLWAITをdefineしてみた所、症状はおさまったように見えます。

根本的には、こちらで使用しているFreeBSDのNICがどうも怪しく負荷をかけるとパケットロスかなにかが起きておかしくなっているのだと思うのですが・・・
それでもなんとかリカバリー出来るとありがたいです。

その後快調に稼働しております。
また何かありましたらご報告いたします。

サイズ指定の場合で、総セクタ数が不明な場合は、
なにかしらで正確に調べないとダメかもしれない。
利用するアプリによっては端数を切り上げや四捨五入で、
正確な値を表示していない可能性がありますので、
表示されたサイズで確保できないと言う問題によく陥るようです。
これは直接デバイスを使う場合のFAQですね。

＞前記のエラーは依然表示されますが
この部分は既存ファイルサイズが指定されたサイズより大きいか判定する部分ですので、サイズ指定が正しければ（デバイスと等しいか小さい場合）無視しても問題ありません。

Autoに関しては対応していないのでどうしようもないです。はい。
他のOSも見て必要な処理を追加する必要があります。
今後の対応リストにでも入れておきます。

なお、サイズをAutoで指定した場合は
istgt_lu.c: 642:istgt_lu_get_filesize: ***ERROR*** lstat not REG nor CHR
istgt_lu.c:1303:istgt_lu_add_unit: ***ERROR*** LU1: LUN0: Auto size error
istgt_lu.c:1555:istgt_lu_init: ***ERROR*** lu_add_unit() failed
istgt.c:1417:main: ***ERROR*** istgt_lu_init() failed
となり、やはり動作しませんでした。直接サイズ指定で動作したので支障はありませんが。

MacでのiSCSIターゲット作成は希少なので大変助かっています。
どうもありがとうございます。

istgtの起動をシェルから

istgt -D -t all

のように起動するとトレースログが出るので、
どの位置で問題があるのかを調べて頂けますか？
ログが多い場合はメール(ソースのREADME等に記載)でも構いません。
よろしくお願いします。

しかし、Initiatorを何とかしないと行けませんねぇ。Userlandで動くInitiatorって許かにあるんでしょうかね。ほとんどの実装はkernel moduleだったりDevice Driverだったりするので、NetBSD-Xenでは使えない…

istgtは認証を使うのを優先で、なくてもOKなポリシーなので、
認証を使ってもいいと言われると優先して使っちゃいます。
（イニシエータ側が利用するものを提示します）
認証を切るという考えは想定していなかった為に設定変更できません(汗)

そしてNetBSDのシーケンス番号がistgtの期待しているものと違うらしく、
無修正では、そんな番号は使えません的にリジェクトしちゃいます。

pkgsrcに登録されたからには修正されるのは時間の問題かと思いますけど。
こちらでも時間があるときに調べてみます。

※追記：NetBSDのイニシエータはオーバーフローもアンダーフローも対応できていないようです。

内容は理解出来ました。
今まで、iscsifsで認証しか使ったことがないんですが、認証を使わずに接続する時のコマンドライン引数をご存知でしたら教えてください。

# もしかして、authsを削除するだけとかだったら情けないなぁ :-(

1番は不明ですが、2番についてはお察しの通りで認証ができません。
理由はNetBSDの実装(イニシエータ)が長いパラメータ(CHAP認証の乱数)
を受取らないので認証ありでは接続が無理なのです。
istgtに限らず、認証データなどに長いものを要求するイニシエータと
NetBSDのターゲット間でも同様に接続できません。
NetBSDのターゲットとイニシエータしか使わないなら表面化しないから
きっと他の用途に使っている人が少ないのでしょうね。

ついでに質問です。

前提
　istgtはMacOS-X (Leopard|snowLeopard) (Intel/PPC) とNetBSD 5.0(amd64)で動かしている
　initiatorには、Global SAN iSCSI (MacOS-X snow Leopard(Intel))と、NetBSDのiscsifs(NetBSD/amd64) で動かした。症状は共通

1) どうもGlobal SAN iSCSIで認証がうまくいきません。うまくいっている人居ますか？
自分の設定を疑っていますが、どう直したものやら…
2) NetBSDのiscsifsでうまく接続出来ません。うまくいっている人居ますか？
これは本当に謎です。
ちなみに、-u を指定しないと、ユーザー名を指定しろと怒られます。
根は同じで、認証がうまくいっていないんじゃないかと思いますが。

>>>>> NetBSD 側 <<<< 256.
pid 1324:initiator.c:1980: ***ERROR*** param_text_parse_offer() failed
pid 1324:initiator.c:1813: ***ERROR*** initiator_cmd_t failed
pid 1324:initiator.c:642: ***ERROR*** login_phase_i() failed
pid 1324:initiator.c:1160: ***ERROR*** enqueue_worker: discovery_phase() failed (ignoring command)

>>>>> istgt側(istgt -D) /Console <<<<>>>> syslogには何も出てませんでした <<<<<

今晩、MacOS-X Leopard Server(PowerPC)で動作確認する予定です。