On 09/24/13 at 01:49pm, Vivek Goyal wrote:
On Tue, Sep 24, 2013 at 09:43:45AM -0400, Vivek Goyal wrote:
[..]
> > > > +kdump_is_ibft() {
A better name might be "target_is_ibft_lun()"
Great. Will do.
> > > > + local path=$1
> > > > + local tgt_name fw_tgt_name
> > > > +
> > > > + tgt_name=$(kdump_iscsi_get_rec_val "$path"
"node.name")
> > > > + fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1
== "node.name" {print $3}')
> > > > +
> > > > + [ -n "$fw_tgt_name" ] && strstr
"$fw_tgt_name" "$tgt_name"
I vaguely remember that one problem with ibft in the past was that one
could not tell reliably whether a lun came from ibft configuration or
not.
I get the target name of current session and see if it's in the list of
ibft exported target names. If yes, I assume the current session is ibft
lun.
It's not accurate, I know. When there's two network card, say eth{0,1}
both configured ibft, each target is tgt{0,1}. After system boot, I
login tgt1 using eth0. This case will fail target_is_ibft_lun().
So how does above work. Can you give an actual example.
Not now. I can show you once I get a machine with ibft configured.
Is this generic enough to work on wide variety of iscsi ibft
configurations? So after this, should we start claiming supporting iscsi
using ibft as kdump target?
I think the first thing I need to figure out is how many use case we
need to cover. I'm not familiar with this unfortunately...
Once we can cover all the cases and also have well tested by QE, I think
yes we can say ibft is supported.
Thanks
WANG Chao