Long timeout when creating new iSCSi volume

Hi,

What is the normal timeouts/outages when creating new volumes (iscsi file i/o with init), when I tried to add a new volume all VMWare servers was unresponsive / dead slow for several minutes until i canceled the creation of the new volume (they run the vms from iscsi and have esx installed localy)

Is this normal when adding a volume ? Is it possible to create volumes when a system is in use or should I turn everything off when creating a disk volume ?

The server is a Supermicro X7DWE, E5405, 8GB RAM, Adaptec 5445 SAS.
The volume that had the outage was located on a raid set using 6xSeagate Cheetah NS - 400GB SAS while the raid set I added the volume to is a set using 6xSeagate Barracuda ES.2 - 1TB SAS

In the logs I get this, I don't know if it is related
2008-11-11 21:18:58 cmnd_abort(1143) ba73cb 1 0... (0/1)
2008-11-11 21:18:53 cmnd_abort(1143) ba73c4 1 0... (1/1)
2008-11-11 21:18:52 cmnd_abort(1143) 24fbe59 1 0... (1/1)
2008-11-11 21:18:48 cmnd_abort(1143) b7d930 1 0... (1/1)
2008-11-11 21:18:43 cmnd_abort(1143) b7d8ec 1 0... (1/1)
2008-11-11 21:18:42 cmnd_abort(1143) ba73ac 1 0... (1/1)
2008-11-11 21:18:42 cmnd_abort(1143) b7d8ca 1 0... (1/1)


--
Rasmus Fauske

Ran into this myself. Had just one Hyper-v Guest running and decided to setup an File i/o volume 2 terabyte in size. My one DSS session almost came to a standstill while this was initializing. This is with an Areca controller with 2gig memory and SM motherboard with quad core preocessor with 12 gig memory. Have sixteen 1 terabyte drives in Raid 6. Could raid 6 be the bottleneck?

Before I add any more connections I think I need to initialize all the volumes I want before putting this in production. I guess my dream of being able to carve up and initialize disk space as needed on the fly is not possible with DSS.

Do others see this as well when initializing new file i/o volumes on production systems??:confused:

more idea plz.

What version are you running?

the command aborts are timeouts, The data will get resent
Did you guys try to set both MaxRecvDataSegmentLength and MaxXmitDataSegmentLength to 65536
it is set from the console iSCSI Daemon options / Target options

Running latest DSS V6. No obvious errors in my error log.

Not saying this is bad or good, trying to understand if this is normal from those who have had DSS in production and had occasion to create a File I/O Target during the busiest part of the day as to whether or not they notice a large performance decrease from their attached production systems

It would be nice if there was a way to specify what percentage of the system to allow for initializing a new File I/O volume so as not to cause this perfomance dropoff.

Doing some more testing I created a File i/o volume without initialization. Seemed to work ok and the performance was comparable to another volume that I had done with file i/o with initialization, but the not initialized file i/o was created in seconds!

So I'm wondering what the downside is to using uninitialized File i/o volumes as they seem to not cause the huge performance drain when they are initializing. In the knowledgbase it says:


File IO no initialization:
XFS uses first free block for saving the data – no need to use „SEEK” command.
High performance while „random write”, low performance while sequential read.‏

File IO with initialization:
System must perform a real SEEK in order to read/write the data.
XFS table has to be read and updated.
More stable than “not initialized” volume.

Trying to understand what More Stable means. Will my uninitialized File i/o volumes blow up sometime in the future? I would think if that were the case I don't think initialization would not be an option under file i/o but rather mandatory.

Has anyone out there in Open-e forum land used uninitialized file i/o volumes and had problems?? Or not??

Thanks!

Can anyone from Open-E clarify what more stable then "not initialized" volume means in the sentence below from one of their knowledgebase articles.??

File IO no initialization:
XFS uses first free block for saving the data – no need to use „SEEK” command.
High performance while „random write”, low performance while sequential read.?

File IO with initialization:
System must perform a real SEEK in order to read/write the data.
XFS table has to be read and updated.
More stable than “not initialized” volume.

Whats the purpose of having the option when creating new ISCSI voumes to initialize or not initialize if there is any possiblity of damage?

Thanks!

I too experienced very slow performance on my system while I was creating an iscsi volume with initialized file i/o. I was trying to figure out what was causing all the problems with the ESX servers and it took me half way through the night when I remembered I had started the volume creation process. Since it was 50% complete I let it finish while my customers were complaining. I told them I was doing performance upgrade. =P
Also using dss v6.

When using the initialized file i/o this is like a low level format writing with all 0's and does consume resources as with any low level format. EMC systems require this always but do not force this operation only as an option if you wish to perform this. Use the initialization first for all your logical volumes before production use.

anyway to set the priority on this lower?

Not yet but we are looking into having this feature at a later release for V6.

Thats nice the EMC makes users initialize, but why make it an option in Open-E if there is a downside like total file corruption?

I have 1 initialized and 3 uninitialized File I/O volumes and all have similar performance. How much exposure do I have with the uninitialized File I/O volumes developing problems down the road? :confused:

Funny most engineers that told me that use the EMC dont like this where they dont have an option where we provide it. Like I said you dont have to do it but it provides for more data security as in our knowledge base and other docs on the net.