*NOT* init'ng file/IO volumes

[enealDC]

What is the risk here?
For example, if I use RAID5, my disks have already been initialized with either the write or clear method. What am I risking here. What issues have people encountered when they have not done this?

[To-M]

Initialize:

This option is available when creating an iSCSI (I) or Fibre Channel (FC) volume. It is here for security reasons. The volume will be initialized after the creation process. There can be only one volume being initialized at any one time. If there are more volumes to be initialized, a Waiting indicator will appear near the one(s) enqueued. Using the button next to the indicator you can send the initializing volume to the back of the initialization queue. Every volume that is waiting for initialization in queue can also be sent to the back of queue.

Initialization is made for data protection. Basically when you initialize your volume you fill it with zeros, then when you write over the volume the space that has no data will be protected.

Its a low level format, and many big companies are using this, EMC for instance force you to do it. It’s a good feature. It may take time for big volumes, but it’s so important..

[enealDC]

I guess my point is that it's sort of redundant right? If disk blocks underneath the volume have already had zeros written across them - then why do it again?
I'm trying to understand what are the real world implications. E.G Customer A didn't init a volume and had some bad things happen.

[Sh-J]

Dear enealDC,

The initialization here is not redundant, as initializing the Logical Volume will be on file system level, while the RAID is on the block level. Our tests shows that initializing logical volumes are more stable.

Regards,
SJ

[alex1]

should i enable this when expanding an existing iSCSI volume? (eg 100gb)

will it initialize only the new additinal volume (eg 50gb) or the whole lot and wipe my current data? (eg 150gb)

[To-M]

Only the initialized amount.