[Çözüldü] Hp 380DL380 G10 Parity Initialization Status Hakkında

Sizin durumda "Surface Scan Priority" tamamen etkiliymiş ve konu çözülmüş.
Ben nedeni ve diğer etkileyenleri de çeşitlendireyim kısaca.
Bizler std bu tür geçişleri ve operasyonları mesai saatleri dışında yapın deriz çünkü array üzerinde IO olup olmaması önemlidir. Party işlemleri bir background task'tır ve controller'lar IO etkinliğini parity'e tercih eder. Yani siz ekranda başladığını görürsünüz ama günler boyu ilerlemez aslen IO yoğun olduğu ve sizin de bulduğunuz gibi daha önce yapılmamış detay ayarlar kaynaklı vs aslında partiy ve diğer check'ler aslen yapılmıyordur. Surface Scan Priority idle konumunda sadece IO olmadığında back. tasklar çalışır mesela sizin durumda hafta sonunda, gece vs vm'ler kapatılsa yada sunucu bios konumunda tutulsa yine hızlı tamamlanabilirdi. Diğer yanıt güncellediğimiz konuda sorular üzerinden bu tür şeyler konuşmuştuk.
Diğer perf. ayarları üzerinde diğer etkileyen şeyler ctrl'larda mem ve lisans olup olmamasıdır. Bu 2'si olmadığında rebuild süreci çok daha uzun sürer, ay bile sürebilir. Ama bunun için devasa bir pool olması gerekli. Sunucu malum çalışmaya devam eder ancak o süreç dahilinde yine kritik disk hatalarına da açık halde olur.
Cache (BBWC/FBWC) olmadığında zaten bazı perf. ayarları etkin olmaz ve partiy hesapları sadece disk, cpu üzerinde yapılabilir bu da çok uzun sürer. Yani ctrl tasarlandığı özellikleriyle tam perf. ile çalışmıyor gibi denebilir. Write-back options burada da etkilidir.
Normalde Advanced Pack lisansın direkt bir etkisi yok ama dolaylı etkisi var yine bazı ctrl'larda lisansız bazı ayarlar seçilemiyor ve asıl fark sadece bunlar task olduğu için detayları yönetememek kaynaklı gerçekleşebiliyor. Yani cache varlığı kadar kritik birşey değil.
Herşey var fakat yine uzun sürüyor diyelim bunu hesaplatacak bir calculator yok ne yazık ki çünkü her array'in durumu özel. 
En büyük etki cache, IO dışında veri yoğunluğu, doluluk kaynaklı gerçekleşiyor bu kısmı anlatmak zor disklerin sector mantığı gibi raid array sector'lerin çalışma, tutulma tekniklerini okumak gerekli. Herşey doğru kurguda olsa bile günler boyu sürebilir özellikle IO olduğunda.
Sık karşılaşılabiliyor. Mesela zamanında herşey doğru ayarlanmış diyelim, array yıllar yıllar önce kurulmuş ama cache pili bitmiş farkında değiller ve doluluk %98. Fazla fazla hot spare'iniz yoksa o işin geri dönüşü her ideal altında 3-4 gün sürebiliyor. Sizdeki duruma göre süre oluşumu zaten eksiklere işaret olurdu ancak pool yoğunluk durumu çok olumlu taraftaymış.
Belki anlaşılması için başka bir şeye değineyim. Mesela giriş ve orta ölçekli NAS'larda bu party, rebuild durumları çok daha uzun sürer çünkü özellikle ucuz 4'disk'lilerde gerçekte fiziksel bir controller olmaz, raid array software yönetilir, dolayısıyla ilgili karmaşık matematik hesaplar cpu ve disk yüzeylerinde ki party'ler okunarak, çaprazlanarak yapılır. Bunlara göre cache, pili olmayan bir raid kartlı sunucu bile çok üstel durumda diyebiliriz.
İlgili olabilecek aklıma gelenler bunlar controll'ların ilgili doc'larından cache ayarlarının okunmasını özellikle tavsiye ederim çünkü bazıları kritik.   

Üstad detaylı yanıtın için teşekkürler.

Benim durumda çözülmedi 🙂 (yapmadım hp den dönüş olmayınca)

Hp ye yazdım linkteki işlemi yapayım mı diye dönüş gelmedi henüz.

Ciddi IO yok sistemde sanalda dc var birde veri boyutu fazla olan file server var.

Resource Mon. baktım Sanal ve Hypervizor sunucuda disk I/O düşük aslında.

3 TB Terminal serverımda HP 380 G9 sunucuda bile anlık I/O daha yüksekken Disk parity si 1-2 Günde bitiyordu.

Ha bitmiş yazmışsın linke göre ben onu bitti diye okudum konu da çözüldü diye işaretlenince senin sorun zaten çözüldü diye anlaşıldı.:)
Surce scan ayarını idle dan değiştirebilirsin sorun olmaz. Ama önce pilden felan emin ol write cache ayarları enable olsun. 
Söylediğin vm ler io için yeterli zaten.
Ayardan sonra yapabiliyorsan gece sunucuyu kapatıp ilo dan bir izle birkaç yüzde hızlı artıyorsa daha kısa sürede bitecek demektir zaten.
Aksi bir durumda ise boş VM'ler dahi sürünmeye başlar oradan anlarsın, adımları gelir alır, gönderdiğin log'a göre hpe nin dönüşünü beklemen daha iyi olur. 

Merhabalar,

Parity queded olarak gözüküyordu bende işlem yapıyor sanıyordum lakin işlem yapmıyor demekmis . Hata logunda birislem yapmanıza gerek yok arkaplanda işlem yapılıyor uyarısı geçersiz bu durumda.

Parity durumu eğer başladıysa işlemde yazmaliymis.

Sanal sistemleri kapadim. Hypervizor sunucu yeniden başlattım f10 ile yapılandırma ekranına girdim hiç işlem yapmadan 45 dakika bekledim

Sunucu yeniden başlattım Storage admin den baktigimda parity %20 olmuştu. 😄

3 saat içinde parity tamamlandı hata loglari temizlendi.(Vm sunucular kapalı idi bitene kadar)

Geri dönüş ve bilgi için teşekkürler, elinize sağlık, geçmiş olsun.

Evet, task daha kuyruğa girmemiş. Seninki de aynı konuymuş. İleri ki durumlar için o idle ayarını değiştirebilirsin.
Bir boş vm çalışması bile yüksek resource işlemidir aslında cpu ve disk yönünde, kaynak tüketimi ekranlarında yüksek birşey görmediği için insanlar öyle yorumlanmıyor.
Yalnız bu raid back task süreçleri herşey de aynı değil güçlü raid ctrl ve storage'lerde farklı işliyor burada konuşulanları sabit almamak lazım.
Konu asıl şimdi çözüldü herhalde, kolay gelsin.