ABORT_TASKからエラーリカバリーができなくなる可能性がある問題に
対応するため若干の修正を加えました。
Ivan Vorasさんから提案とパッチを頂きましたので追加してみました。
istgt (tarball): istgt-20010125.tar.gz
修正版をご利用ください。
作成方法：
# cd /path/to/work
# tar zxf /path/to/istgt-20100125.tar.gz
# cd istgt-20100125
# ./configure
# make
# make install
# make install-docデーモンの再起動方法：
# /usr/local/etc/rc.d/istgt restartMD5 (istgt-20100125.tar.gz) = 1af4006dd185b2e2326a356ef17dc2cc
SHA256 (istgt-20100125.tar.gz) = 028dd131300d24b2c425543ef84805735a9361cac79437c829a5062f84532618
主な修正点：
内部でスレッド名を保持するようになりました。
実行待ちのタスクを強制終了させるフラグなどを追加しました。
スレッド条件待ち時間の最小を5秒まで短縮しました。
連絡が遅くなりましたが、istgt 20100125版が以下の環境で動作しました。
1) MacOS-X Leopard Server(Intel)
2) MacOS-X SnowLeopard(Intel)
今晩、MacOS-X Leopard Server(PowerPC)で動作確認する予定です。
MacOS-X Leopard Server(PowerPC)でも動作しました。
Global SAN iSCSIで、認証を使わなければDiskを認識しました。
ついでに質問です。
前提
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には何も出てませんでした <<<<<
報告ありがとうございます。
1番は不明ですが、2番についてはお察しの通りで認証ができません。
理由はNetBSDの実装(イニシエータ)が長いパラメータ(CHAP認証の乱数)
を受取らないので認証ありでは接続が無理なのです。
istgtに限らず、認証データなどに長いものを要求するイニシエータと
NetBSDのターゲット間でも同様に接続できません。
NetBSDのターゲットとイニシエータしか使わないなら表面化しないから
きっと他の用途に使っている人が少ないのでしょうね。
回答、ありがとうございます。
内容は理解出来ました。
今まで、iscsifsで認証しか使ったことがないんですが、認証を使わずに接続する時のコマンドライン引数をご存知でしたら教えてください。
# もしかして、authsを削除するだけとかだったら情けないなぁ :-(
簡単にNetBSDのソースを見てみましたけど、
現状で接続するのは無理そうに見えます。
双方に修正が必要と思われます。
istgtは認証を使うのを優先で、なくてもOKなポリシーなので、
認証を使ってもいいと言われると優先して使っちゃいます。
（イニシエータ側が利用するものを提示します）
認証を切るという考えは想定していなかった為に設定変更できません(汗)
そしてNetBSDのシーケンス番号がistgtの期待しているものと違うらしく、
無修正では、そんな番号は使えません的にリジェクトしちゃいます。
pkgsrcに登録されたからには修正されるのは時間の問題かと思いますけど。
こちらでも時間があるときに調べてみます。
※追記：NetBSDのイニシエータはオーバーフローもアンダーフローも対応できていないようです。
ああ、そういうことなんですね。理解しました。
しかたがないのでNetBSD iSCSI-targetと組み合わせることにしのぐことにします。
しかし、Initiatorを何とかしないと行けませんねぇ。Userlandで動くInitiatorって許かにあるんでしょうかね。ほとんどの実装はkernel moduleだったりDevice Driverだったりするので、NetBSD-Xenでは使えない…
はじめまして。
Mac OS Xでも動作するとのコメントを拝見し、Snow Leopard上で試してみたのですが、LogicalUnitにデバイスファイルを指定したところ、
istgt_lu.c: 642:istgt_lu_get_filesize: ***ERROR*** lstat not REG nor CHR
とのエラーが出て動作しませんでした。
容量を直接指定してもAutoで指定しても同様です。
Macでの動作は想定していないのは承知しておりますが、もしどなたかエラーを回避する方法をご存知でしたらお知恵をお貸し下さい。
えっと、詳しい状況がわからないのですが、
サイズ指定が出来ていれば使えると思っていましたが、
どのような設定をしましたか？
istgtの起動をシェルから
istgt -D -t all
のように起動するとトレースログが出るので、
どの位置で問題があるのかを調べて頂けますか？
ログが多い場合はメール(ソースのREADME等に記載)でも構いません。
よろしくお願いします。
すみません、落ち着いて一からやり直したところ、サイズを直接指定した場合については動作しました！
わざわざご回答頂いたのに申し訳ありません。混乱した状態で質問していまい、お恥ずかしい限りです…。
ただ、前記のエラーは依然表示されますが、これは無視して構わないということでしょうか？
なお、サイズを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ターゲット作成は希少なので大変助かっています。
どうもありがとうございます。
何かしらの反応があるのはとても嬉しいので問題ありません。
サイズ指定の場合で、総セクタ数が不明な場合は、
なにかしらで正確に調べないとダメかもしれない。
利用するアプリによっては端数を切り上げや四捨五入で、
正確な値を表示していない可能性がありますので、
表示されたサイズで確保できないと言う問題によく陥るようです。
これは直接デバイスを使う場合のFAQですね。
＞前記のエラーは依然表示されますが
この部分は既存ファイルサイズが指定されたサイズより大きいか判定する部分ですので、サイズ指定が正しければ（デバイスと等しいか小さい場合）無視しても問題ありません。
Autoに関しては対応していないのでどうしようもないです。はい。
他のOSも見て必要な処理を追加する必要があります。
今後の対応リストにでも入れておきます。
ご返答ありがとうございます、了解いたしました。
その後快調に稼働しております。
また何かありましたらご報告いたします。
はじめまして
istgt 20100125版をFreeBSD 8.0のportsからインストールして使用していますが、ネットーワークの負荷が高くなるとどうも動きません。
負荷が高いと以下のようなメッセージが表示されます。
—
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がどうも怪しく負荷をかけるとパケットロスかなにかが起きておかしくなっているのだと思うのですが・・・
それでもなんとかリカバリー出来るとありがたいです。
blindspot 様
Auto size errorについてNetBSD, Mac OS X, Linuxでの必要と思われる処理を20100407で追加してみました。
ただし、未検証なので動かないかもしれません。まずは新バージョンをお試しください。
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に限らずギガビット環境のチューニングになりますので、
他のサービスについても影響の有無を調べたほうが良いかもしれません。
そうですね環境を書いていませんでしたね
ターゲットはFreeBSD 8.0でZFSを使用しています
ただ、ZFSは仮想ボリュームは使用していませんが、圧縮をcompression=lzjbで使用しています。
イニシエータは、Mac OSX SnowLeopardのglobalSAN 4.0.204を使用してます。
(余っていたあまり大きく無いディスクを、OSXのTimeMachineで使用したかったもので・・・)
とりあえず、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