On 12/30/2010 02:16 AM, Or Gerlitz wrote:
Mike Christie wrote:
It looks like sg_map cheats and does not look at sysfs for this.
Will do one or the other.
It looks like some sg_map26 commands are broken with your kernel config
too now (sg_map26 uses sysfs where sg_map does not).
yes, sg_map26
Mike Christie wrote:
I do not know. We do not do it in Fedora either.
okay, so I guess we'll leave it for that time being...
Or.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To
Mike Christie wrote:
It looks like sg_map cheats and does not look at sysfs for this.
Will do one or the other.
It looks like some sg_map26 commands are broken with your kernel config
too now (sg_map26 uses sysfs where sg_map does not).
yes, sg_map26 is very much broken indeed on my kernel...
Mike Christie wrote:
Or Gerlitz wrote:
I think you said at some point this may happen if I use old udev
bits, what version of udev you're using?
147. I do not have any udev wait_for_sysfs: waiting messages in my log
so it looks like a udev issue.
yep, using that udev version eliminated
On 12/27/2010 04:20 AM, Or Gerlitz wrote:
Mike Christie wrote:
Or Gerlitz wrote:
I think you said at some point this may happen if I use old udev
bits, what version of udev you're using?
147. I do not have any udev wait_for_sysfs: waiting messages in my log
so it looks like a udev issue.
On 12/27/2010 07:09 PM, Mike Christie wrote:
On 12/27/2010 04:20 AM, Or Gerlitz wrote:
Mike Christie wrote:
Or Gerlitz wrote:
I think you said at some point this may happen if I use old udev
bits, what version of udev you're using?
147. I do not have any udev wait_for_sysfs: waiting
On 12/23/2010 02:05 PM, Or Gerlitz wrote:
[...] you can see that the kernel scsi code detected the new scsi host (98) /
lun
on it and assigned the sdd device for that lun, but I can tell that this all
happens only @
16:07:18 which is seven seconds --after-- the lun was detected @ 16:07:11
If
Mike Christie wrote:
Do you mean the /dev/sdX's getting created or the kernel scsi scanning code
detecting luns?
I did not see either.
Mike, from this log you can see that the kernel scsi code detected the new scsi
host (98) / lun
on it and assigned the sdd device for that lun, but I can
[...] you can see that the kernel scsi code detected the new scsi host (98) /
lun
on it and assigned the sdd device for that lun, but I can tell that this all
happens only @
16:07:18 which is seven seconds --after-- the lun was detected @ 16:07:11
If we both use the same .config is there
On 12/19/2010 06:38 AM, Or Gerlitz wrote:
Mike Christie wrote:
[...] I think in general the iscsi tools are using sysfs incorrectly.
I think I need to use the sysfs code udev is using.
Again, I'm more not less (...) worried from the original problem of the
luns appearing with delay on the
Mike Christie wrote:
[...] I think in general the iscsi tools are using sysfs incorrectly.
I think I need to use the sysfs code udev is using.
Again, I'm more not less (...) worried from the original problem of the
luns appearing with delay on the initiator node, I wonder if anyone else
was
On 12/16/2010 01:24 AM, Or Gerlitz wrote:
can it explain the delay in exposing the luns to the initiator scsi stack?
Not sure what you mean exactly.
The initiator will do iscsi login then scan for devices by doing echo -
- - /sys/class/scsi_host/hostX/scan. The scsi layer handles this by
On 12/15/2010 03:21 PM, Mike Christie wrote:
# iscsiadm -m session -P 3
The iscsiadm -m session output does not rely on udev or anything that
udev creates like the /dev nodes. iscsiadm just reads sysfs. The missing
output could be due to a change in the sysfs layout again. Could you
send me
On 12/16/2010 07:01 PM, Mike Christie wrote:
On 12/15/2010 03:21 PM, Mike Christie wrote:
# iscsiadm -m session -P 3
The iscsiadm -m session output does not rely on udev or anything that
udev creates like the /dev nodes. iscsiadm just reads sysfs. The missing
output could be due to a change
Hi Mike,
With kernel 2.6.37-rc5 (the latest upstream release) I see some udev related
issue, when doing login (I'm using iscsi-initiator-utils-6.2.0.871-0.16.el5),
the following appears in the system logs
udevd-event[12383]: wait_for_sysfs: waiting for
On 12/15/2010 08:47 AM, Or Gerlitz wrote:
Hi Mike,
With kernel 2.6.37-rc5 (the latest upstream release) I see some udev related
issue, when doing login (I'm using iscsi-initiator-utils-6.2.0.871-0.16.el5),
the following appears in the system logs
udevd-event[12383]: wait_for_sysfs: waiting
Mike Christie wrote:
Could you send me your kernel .config?
Yes I do
The other udev messages could also be caused by a older udev and a sysfs
change
can it explain the delay in exposing the luns to the initiator scsi stack?
Or.
--
You received this message because you are subscribed to
17 matches
Mail list logo
