RE: [RFC]-Sysfs attributes of /sys/firmware/ibft files
Michael wrote: >On Monday 23 February 2009 12:46:04 shyam_i...@dell.com wrote: >> Does anyone know the reason for file attributes of the files created >> in /sys/firmware/ibft/<>/files being readonly? >> >> Can't dynamically changing parameters like target ip-addreseses, iqns >> and others etc. be configurable through userspace via sysfs? >> >> I think we do have precedence of firmware parameters being modified >> using sysfs. > >You cannot modify the iBFT in situ, because it contains a number of variable-length strings and you do not (in most cases) know how much space is >available for adding further strings. See> > > http://markmail.org/message/e7p377jpkidpg3vr> > >for a more detailed explanation of a related issue. > >You could modify the (potentially) cached values returned by sysfs, rather than modifying the actual table, but that would then cause inconsistent >results between clients using sysfs and clients using the pre-sysfs method of directly scanning through base memory.> > >(I don't see why you would want to modify the iBFT anyway, but that's a separate issue.) Part of it is out of lazyness and I guess sysadmins will agree. I don't want the system to reboot to reconfigure the target IP addresses and iqn's when I know they have changed while I am booted into OS. The other thing is if I have an iSNS server configured I can just issue the change through sysfs especially if my NIC doesn't talk iSNS. Shyam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
open-iscsi@googlegroups.com
Hi, Windows does not support disks that have been formatted to anything other than a 512byte block size. Block size refers to the low level formatting of the disk and not the cluster or allocation size used by NTFS. Be aware that using a disk with a block size larger than 512 bytes will cause applications not to function correctly. You should check with your iSCSI target manufacture to ensure that their default block size is set to 512 bytes or problems will likely occur.For further reference and knowledge you can consult www.microsoft.com/document www.Stonefly.com and www.DNFstorage.com. Storage Solution Group. --~--~-~--~~~---~--~~ 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: [RFC]-Sysfs attributes of /sys/firmware/ibft files
On Mon, Feb 23, 2009 at 09:27:08PM +0530, shyam_i...@dell.com wrote: > > Konrad wrote: > >On Mon, Feb 23, 2009 at 06:16:04PM +0530, shyam_i...@dell.com wrote: > >> > >> Does anyone know the reason for file attributes of the files created > >> in /sys/firmware/ibft/<>/files being readonly? > > >Yes. The spec does not allow you to write to the iBFT - only read. > > Thanks Konrad. I guess I should have read the spec before commenting (:. The spec is completly silent about this. Just talks about data values and leaves the 'write'/generate part to vendors. > > >> > >> Can't dynamically changing parameters like target ip-addreseses, iqns > > >> and others etc. be configurable through userspace via sysfs? > > >Can't do. Well if you are using the IBM blades, they do have a Java > tool (Blade Configuration something) that allows you to set those > entries and on > > >bootup the BIOS would generate them. The mechanism it uses to write > that data is completly vendor-specific however. > > You mean the content generated by the Java tool is stored somewhere and > the BIOS reuses the content to genereate them as the spec mandates only > the BIOS to generate the iBFT. Exactly. (Thought to be exact, the word BIOS should be used loosly, as the NIC firmware could be constructing the iBFT, and not neccesarily the BIOS). --~--~-~--~~~---~--~~ 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: [RFC]-Sysfs attributes of /sys/firmware/ibft files
Konrad wrote: >On Mon, Feb 23, 2009 at 06:16:04PM +0530, shyam_i...@dell.com wrote: >> >> Does anyone know the reason for file attributes of the files created >> in /sys/firmware/ibft/<>/files being readonly? >Yes. The spec does not allow you to write to the iBFT - only read. Thanks Konrad. I guess I should have read the spec before commenting (:. >> >> Can't dynamically changing parameters like target ip-addreseses, iqns >> and others etc. be configurable through userspace via sysfs? >Can't do. Well if you are using the IBM blades, they do have a Java tool (Blade Configuration something) that allows you to set those entries and on >bootup the BIOS would generate them. The mechanism it uses to write that data is completly vendor-specific however. You mean the content generated by the Java tool is stored somewhere and the BIOS reuses the content to genereate them as the spec mandates only the BIOS to generate the iBFT. -Shyam Iyer. --~--~-~--~~~---~--~~ 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: [RFC]-Sysfs attributes of /sys/firmware/ibft files
On Monday 23 February 2009 12:46:04 shyam_i...@dell.com wrote: > Does anyone know the reason for file attributes of the files created in > /sys/firmware/ibft/<>/files being readonly? > > Can't dynamically changing parameters like target ip-addreseses, iqns > and others etc. be configurable through userspace via sysfs? > > I think we do have precedence of firmware parameters being modified > using sysfs. You cannot modify the iBFT in situ, because it contains a number of variable-length strings and you do not (in most cases) know how much space is available for adding further strings. See http://markmail.org/message/e7p377jpkidpg3vr for a more detailed explanation of a related issue. You could modify the (potentially) cached values returned by sysfs, rather than modifying the actual table, but that would then cause inconsistent results between clients using sysfs and clients using the pre-sysfs method of directly scanning through base memory. (I don't see why you would want to modify the iBFT anyway, but that's a separate issue.) Michael --~--~-~--~~~---~--~~ 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: [RFC]-Sysfs attributes of /sys/firmware/ibft files
On Mon, Feb 23, 2009 at 06:16:04PM +0530, shyam_i...@dell.com wrote: > > Does anyone know the reason for file attributes of the files created in > /sys/firmware/ibft/<>/files being readonly? Yes. The spec does not allow you to write to the iBFT - only read. The BIOS (or the firmware on the NIC, or your PXE boot loader - gPXE) generates these structures during boot. > > Can't dynamically changing parameters like target ip-addreseses, iqns > and others etc. be configurable through userspace via sysfs? Can't do. Well if you are using the IBM blades, they do have a Java tool (Blade Configuration something) that allows you to set those entries and on bootup the BIOS would generate them. The mechanism it uses to write that data is completly vendor-specific however. > > I think we do have precedence of firmware parameters being modified > using sysfs. Yes. Unfortunatly iBFT is not of those firmware structures. > > Thanks, > Shyam Iyer > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[RFC]-Sysfs attributes of /sys/firmware/ibft files
Does anyone know the reason for file attributes of the files created in /sys/firmware/ibft/<>/files being readonly? Can't dynamically changing parameters like target ip-addreseses, iqns and others etc. be configurable through userspace via sysfs? I think we do have precedence of firmware parameters being modified using sysfs. Thanks, Shyam Iyer --~--~-~--~~~---~--~~ 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: question regarding offlined device
On 20 Feb 2009 at 10:47, Mike Christie wrote: > > Ulrich Windl wrote: > > On 19 Feb 2009 at 9:48, Jesse Butler wrote: > > > >> > >> I am trying to troubleshoot why a connection is popping up and down, > >> and finally staying down, with a Linux RHEL 5.2 Open iSCSI / iSER > >> initiator. > > > > Hi! > > > > Maybe that's related: With SLES10 SP1 (x86_64) I have two iSCSI LUNs that > > are > > > I do not think it is related. In your logs tehre is nothing that > indicates the scsi command is timing out. > > In your logs do you see something about a ping or nop timing out? Hi Mike! No, you may be right if those messages aren't sent with a very low log priority. I thought that multipath is sending TUR (Test Unit Ready) commands to different iSCSI paths. Now if various iSCSI paths are flagged bad by multipath, I concluded that either the packets did not make it over the network, or the unit (dis karray) did not respond (for reasons whatever). I may be wrong, but willing to learn ;-) 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: iscsid: connection198:0 is operational after recovery
On 20 Feb 2009 at 11:29, Konrad Rzeszutek wrote: > > On Fri, Feb 20, 2009 at 05:11:24PM +0100, Ulrich Windl wrote: > > > > Hello, > > > > I noticed that I see messages like > > > > Feb 19 01:39:50 rkdvmso1 iscsid: connection198:0 is operational after > > recovery (1 > > attempts) > > > > but no messages telling me that the connection is down (timed out/not > > responding). > > So it's hard to guess when the problem actually occurred. Not knowing the > > sources, > > could it be that the message priority for the failure message (if there is > > any) is > > set too low? > > Try to set 'loglevel=8' on the bootup argument. Also edit /etc/sysconfig/init > and > set the LOG to 8 (if you are using a Red Hat variant of OS). Hi! OK, you are telling me that mesasages are created, but at a lower priority. The issue still is that the failure message should have a higher (or at least equal) priority than the recovery message IMHO. 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 -~--~~~~--~~--~--~---
