EARN $5000-$15000 PER MONTH WITHOUT INVESTMENT
EARN $5000-$15000 PER MONTH WITHOUT INVESTMENT SIMPLE ONLINE SURVEYS AND EARN MORE I HAVE EARN $1000 DAILY VIEW MORE DETAILS http://www.AWSurveys.com/HomeMain.cfm?RefID=anusuyageetha http://www.AWSurveys.com/HomeMain.cfm?RefID=anusuyageetha http://www.AWSurveys.com/HomeMain.cfm?RefID=anusuyageetha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
iscsiadm version 2.0-868 incompatibility with older version
Hi,
SLES10 SP2 ships iscsiadm version 2.0-868, while SP1 had an older version.
For
SP1 I used the following command to set all discovered nodes to auto-login:
for sid in $(iscsiadm -m node | awk '{gsub(/^\[/, ); gsub(/\]/, ); print $1
}'
| sort)
do
iscsiadm -m node -r $sid -o update -n node.startup -v automatic
done
What would be the equivalent for the newer version that says: iscsiadm: node
mode: option '-r' is not allowed/supported?
Yes, I could edit the files in /etc/iscsi/nodes, but I have 32 nodes...
Regards,
Ulrich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: iSCSI resets and raid1
Omko wrote: Thank you for your help! I will try your suggestions shortly. I am not quite sure about the iSCSI reset to be honest, I just tell what the open-e interface tells me. the strange thing is that yesterday I did create some stuff on the open-e san that needed the 'reset' again. and my server continued working just fine, no broken raid this time. Maybe software raid is not supported on top of iSCSI. But if you want a redundant storage layer and you don't have a lot of money it, it's really a great sollution :-) I've used software RAID (1) over open-iscsi with no problems in testing, but I had to move to the latest version of open-iscsi - older versions had problems with creating new targets, and not properly recognising closure of connections from initiators. Its probably just that the hardware device is using an old version of open-iscsi/kernel, and could do with being updated. Matthew signature.asc Description: OpenPGP digital signature The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: Persistent connections across initiator reboot
I am now having 'iscsi-initiator-utils-6.2.0.868-0.18.el5' and performed the steps mentioned in my last post. Still after when I discover using 'iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete',nodes and sendtargets entries gets overwritten. I am also not performing any target configuration changes on the target side in this whole process.Just discovery followed by 'node.startup update to automatic command'.and again performing discovery causes overwriting. Am I going wrong somewhere in the steps? Thanks and Regards, Himanshu Padmanabhi. On Apr 22, 6:38 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Thank you really.But I have not got the expected results. Steps 1. iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete 2. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 -o update -n node.startup -v automatic so '/var/lib/iscsi/nodes/iqn.2009-04.com.systems \:Target1/192.168.30.12\,3260\,1/default' entry changed from node.startup=manual(as specified in iscsid.conf) to node.startup=automatic 3. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 --login 4. Then if I again perform step 1(i.e. discovery),node.startup gets overwritten as 'manual'. I have specified 'node.startup' entry to be 'manual' and will update it to 'automatic' only of those targets which are logged in. What is going wrong.Am I performing the same operations as you told? I am using iscsi-initiator-utils-6.2.0.868-0.7.el5 and it seems to have discovery switches. Do I need to upgrade it? Yeah, just upgrade to: iscsi-initiator-utils-6.2.0.868-0.18.el5 On Apr 21, 7:24 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Yeah.This worked for me.I specified 'node.startup=manual' in 'iscsid.conf'. so running update command to change it to 'automatic' only on login(or I will give option for persistent connection across reboot). But my problem these changes vanish after another discovery command. I login to one target say TAR1, from 30.51 and fired update command to change 'node.startup' to 'automatic'. and then after some time,If I want to login to another target from 30.51,I need to fire discovery command,which will make 'node.startup' of TAR1 changed to 'manual' again due to 'iscsid.conf'. You can pass the discovery commands some flags to indicated how you want it to manage the db. iscsiadm -m discovery -t st -p ip -o new will just add new target portals that are not in the db. iscsiadm -m discovery -t st -p ip -o delete will delete target portals that are in the db but no longer returned by the target in sendtargets discvoery. iscsiadm -m discovery -t st -p ip -o update was supposed to update target portal records that are in the db and returned by sendtargets using the iscsid.conf info. I checked the code today and it actually updates existing records and will add new ones using the iscsid.conf info. Then you can pass in combos. I think you want iscsiadm -m discovery -t st -p ip -o new -o delete this will add new records for new target portals, and delete records for targets no longer returned by the target, and for existing portals it will not update the records so your existing record settings will not be overwritten. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
Is there any method or should I debug to know the exact cause of this overwriting problem? On Apr 24, 6:29 pm, HIMANSHU makhu...@yahoo.co.in wrote: I am now having 'iscsi-initiator-utils-6.2.0.868-0.18.el5' and performed the steps mentioned in my last post. Still after when I discover using 'iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete',nodes and sendtargets entries gets overwritten. I am also not performing any target configuration changes on the target side in this whole process.Just discovery followed by 'node.startup update to automatic command'.and again performing discovery causes overwriting. Am I going wrong somewhere in the steps? Thanks and Regards, Himanshu Padmanabhi. On Apr 22, 6:38 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Thank you really.But I have not got the expected results. Steps 1. iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete 2. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 -o update -n node.startup -v automatic so '/var/lib/iscsi/nodes/iqn.2009-04.com.systems \:Target1/192.168.30.12\,3260\,1/default' entry changed from node.startup=manual(as specified in iscsid.conf) to node.startup=automatic 3. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 --login 4. Then if I again perform step 1(i.e. discovery),node.startup gets overwritten as 'manual'. I have specified 'node.startup' entry to be 'manual' and will update it to 'automatic' only of those targets which are logged in. What is going wrong.Am I performing the same operations as you told? I am using iscsi-initiator-utils-6.2.0.868-0.7.el5 and it seems to have discovery switches. Do I need to upgrade it? Yeah, just upgrade to: iscsi-initiator-utils-6.2.0.868-0.18.el5 On Apr 21, 7:24 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Yeah.This worked for me.I specified 'node.startup=manual' in 'iscsid.conf'. so running update command to change it to 'automatic' only on login(or I will give option for persistent connection across reboot). But my problem these changes vanish after another discovery command. I login to one target say TAR1, from 30.51 and fired update command to change 'node.startup' to 'automatic'. and then after some time,If I want to login to another target from 30.51,I need to fire discovery command,which will make 'node.startup' of TAR1 changed to 'manual' again due to 'iscsid.conf'. You can pass the discovery commands some flags to indicated how you want it to manage the db. iscsiadm -m discovery -t st -p ip -o new will just add new target portals that are not in the db. iscsiadm -m discovery -t st -p ip -o delete will delete target portals that are in the db but no longer returned by the target in sendtargets discvoery. iscsiadm -m discovery -t st -p ip -o update was supposed to update target portal records that are in the db and returned by sendtargets using the iscsid.conf info. I checked the code today and it actually updates existing records and will add new ones using the iscsid.conf info. Then you can pass in combos. I think you want iscsiadm -m discovery -t st -p ip -o new -o delete this will add new records for new target portals, and delete records for targets no longer returned by the target, and for existing portals it will not update the records so your existing record settings will not be overwritten. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Tuning iscsi read performance with multipath Redhat 5.3 / SLES 10 SP2 / Oracle Linux / Equallogic
As an update:
new observed behavior:
- RAW disk read performance is phenomenal (200meg/sec)
- Ext3 performance is 100meg/sec and tps in iostat aren't going about
800 (50k with raw disk).
Some added info:
- This system has an oracle database on it and it's tuned for huge
pages..etc (see sysctl posted above)
On Apr 24, 12:07 pm, jnantel nan...@hotmail.com wrote:
If you recall my thread on tuning performance for writes. Now I am
attempting to squeeze as much read performance as I can from my
current setup. I've read a lot of the previous threads, and there has
been mention of miracle settings that resolved slow reads vs
writes. Unfortunately, most posts reference the effects and not the
changes. If I were tuning for read performance in the 4k to 128k
block range what would the best way to go about it?
Observed behavior:
- Read performance seems to be capped out at 110meg/sec
- Write performance I get upwards of 190meg/sec
Tuning options I'll be trying:
block alignment (stride)
Receiving buffers
multipath min io changes
iscsi cmd depth
Hardware:
2 x Cisco 3750 with 32gig interconnect
2 x Dell R900 with 128gig ram and 1 broadcom Quad (5709) and 2 dual
port intels (pro 1000/MT)
2 x Dell Equallogic PS5000XV with 15 x SAS in raid 10 config
multipath.conf:
device {
vendor EQLOGIC
product 100E-00
path_grouping_policy multibus
getuid_callout /sbin/scsi_id -g -u -s /block/%n
features 1 queue_if_no_path
path_checker readsector0
failback immediate
path_selector round-robin 0
rr_min_io 128
rr_weight priorities
}
iscsi settings:
node.tpgt = 1
node.startup = automatic
iface.hwaddress = default
iface.iscsi_ifacename = ieth10
iface.net_ifacename = eth10
iface.transport_name = tcp
node.discovery_address = 10.1.253.10
node.discovery_port = 3260
node.discovery_type = send_targets
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 4
node.session.cmds_max = 1024
node.session.queue_depth = 128
node.session.auth.authmethod = None
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 15
node.session.err_timeo.lu_reset_timeout = 30
node.session.err_timeo.host_reset_timeout = 60
node.session.iscsi.FastAbort = Yes
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 2
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 10.1.253.10
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.noop_out_interval = 10
node.conn[0].timeo.noop_out_timeout = 30
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
node.conn[0].iscsi.HeaderDigest = None,CRC32C
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No
/etc/sysctl.conf
net.core.rmem_default= 65536
net.core.rmem_max=2097152
net.core.wmem_default = 65536
net.core.wmem_max = 262144
net.ipv4.tcp_mem= 98304 131072 196608
net.ipv4.tcp_window_scaling=1
#
# Additional options for Oracle database server
#ORACLE
kernel.panic = 2
kernel.panic_on_oops = 1
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=524288
net.core.wmem_max=524288
fs.aio-max-nr=524288
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: Tuning iscsi read performance with multipath Redhat 5.3 / SLES 10 SP2 / Oracle Linux / Equallogic
On Fri, Apr 24, 2009 at 02:14:43PM -0400, Donald Williams wrote: Have you tried increasing the disk readahead value? #blockdev --setra X /dev/multipath device The default is 256.Use --getra to see current setting. Setting it too high will probably hurt your database performance. Since databases tend to be random, not sequential. I would think that the databases would open the disks with O_DIRECT bypassing the block cache (And hence the disk readahead value isn't used at all). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
