Do you have a NAR file that you can share? Can you see the same issue in your archived NAR file? One possible scenario can be that an IO is stuck, since the IO is not getting completed the SP thinks that the disk is busy and reports 100% utilization, but since the IO is not getting completed there are not IOPs. Not saying this is the case, but just giving a possible scenario...

Is it possible that you are within your relocation window for fast tiering and although that Raid Group may notbe used, it is moving data up and down tiers?

Hello

Are there any LUN binding/Background Verfy processes?

Alex

That's the weird thing, nothing is going on this pool lun. Everything is landing on the highest tier and my nl-sas spindles are not used, more then enough space left on highest tier in the pool. No iop no mb's going or coming from these spindles but a constant load of 100%.

Hi

I have exactly the same issue on my VNX5700 with a 24 disk pool configured as RAID 10 which contains only 2TB NL SAS drives (so no tiering here).

2 of the disks are constantly showing as 100% utilization (65 IOPS) even when no load is being put on the LUNs.

Is there a way to determine what is causing this I/O?

Regards

Quick question - can you look at the disk lights on the front and see if the lights are flashing constantly?

If no flashing, you may want to open a case to have this investigated.

glen

The SP event logs showed it was doing a background verify....hence the I/O when the LUN was not being used.

A BV like that can be automatically scheduled when a storage processor detects a difference between a group's stripe’s parity and the hard drive’s sector parity.

does VNX run BV when you create a pool LUN or it only applied to RG LUNs ?

Thanks

Keep in mind, that even with a pool, underneath it is creating private RAID groups and across those, private FLARE LUNs (from which the extents are then allocated).  The number of private LUNs created are:

2 * the number of drives in the private RG

For an explanation of how the private RAID Groups are sized based on the amount of disks added and taking in consideration the RAID Type and the recommended multiple, see the comments in the following post:

https://community.emc.com/message/556743

I only wanted to emphasize this as the answer to your question is yes.  The BV is not limited to the thin/thick LUNs the user defines on the pool but instead on the private FLARE LUNs across the private RAID Groups.  You may have noticed that when you create a pool LUN that the option "No initial verify" doesn't exist unlike when you create a FLARE LUN on a (traditional) RAID Group as it is not relevant as the user doesn't have visibility to the private LUNs.

Basically my only point is that even though it is a pool, underneath exist traditional RG's with traditional/FLARE LUNs and the conditions and behavior for BV applies similarly.

Hope this makes sense.