Új hozzászólás Aktív témák

• #10141 #64791808 törölt tag brd #10137

  Új Válasz 2017-09-04 14:40:37 #10141

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #64791808

  törölt tag

  válasz brd #10137 üzenetére

  Maradjunk annyiban, hogy te még nem láttál olyat, ahol ez gondot okozott volna.

  Ha az be van pipálva, akkor a Windows akár 8GB puffert is használ az írásnál, amit nem feltétlenül ürít a lemezre, ennek ellenére sikeresnek és befejezettnek jelzi vissza az írási folyamatot.

  Tehát te azt látod, hogy fúú, így gyorsabban ír a lemez! Pedig nem, mert amit te befejezett másolásnak látsz mondjuk, az még NINCS a lemezen. Csak a pufferban. Szóval a lemezre nem ír gyorsabban ettől.

  Viszont klasszikus probléma, hogy ilyen esetben, mikor még az adat nincs a lemezen, csak a pufferban, és érkezik egy forced shutdown/reboot, akkor Windows a leállítással/újraindulással NEM fog várni a puffer kiürüléséig, csak a registryben ilyen esetre meghatározott timeoutig, ez az XP-nél még 20s volt, a Windows 10-nél már csak 5s. Eredmény: a sikeresen kiírtnak visszajelzett adat mégsem kerül fel a lemezre. Ezt az inkonzisztenciát a Windows a következő indításkor azonnal észreveszi, és - most jön a lényeg - ha saját szoftveres RAID1 vagy RAID5 van konfigurálva, akkor az inkonzisztencia miatt azonnal újraszinkronizálásba kezd.

  No így okoz az az egy kis pipa ilyen gondot. És ha azt gondolod, hogy forced reboot sosem fordul elő, akkor elmondom, hogy jónéhány telepítő, amely újraindítást kér, ha igenre böksz, akkor forced reboot parancsot ad ki.

  RAID1 / RAID5 esetében SOHA nem pipáljuk be ezt az opciót a raidelt lemezeknél, mert egy másolás után rosszkor elindított nyomorult telepítő is okozhat ilyen galibát, a user meg nem érti, miért kezd a rendszer egy fél napig tartó resyncbe.

Új hozzászólás Aktív témák