Long timeout when creating new iSCSi volume

[webguyz]

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??

[glasudmus]

more idea plz.

[symm]

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

[webguyz]

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.

[webguyz]

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!

[webguyz]

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!