AndrewSE91
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Итак, почистил контакты, купил новый sata-шлейф. Всё вроде хорошо. Прогнал чтением на ошибки, ошибок нету. Однако проблема с 65534 якобы нестабильными секторами остались. Начал рыскать инфу по инету, нашёл, кое её очень мало, видать проблема крайне редкая. На официальном сайте Hard Disk Sentinel офицуиальный представитель даёт разъяснение. Цитата: > Problem is that suddenly the current pending sector count jumped to 65535!! :shock: > I have read that this 65535 (actually a binary number) has something to do with HDS which created a buffer underflow condition. Generally, yes, this value is a -1, an underflow. But I can confirm that the underflow is NOT related to Hard Disk Sentinel, but related to the hard disk itself: happened exactly "inside" the hard disk firmware which counts the problems. Usually such underflow may happen when the hard disk can't properly update the proper counter in the S.M.A.R.T. or (during fixing of the sector) decreased the counter twice. For example, if the reallocation starts but can't be completed (for example because of the above mentioned power loss) it may happen that the hard disk already decreased the amount of weak/pending sectors - but then, after power loss and re-started reallocation, the counter decreased again (while processing the same sector). > I believe that it has nothing to do with actual (real) 65535 sectors at all. Yes. The Disk menu -> Surface test -> Read test would show lots of problems when you'd really have so high number of weak sectors. > Very likely it's due to the fact that at prior to the reinitialising scan I used to offset the pending sector count with a negative value, > in order to avoid unnecessary alarms to be triggered. I believe after the reinitialisation the real pending sector count dropped > back to 0, thus combinde with the negative offset value it somehow jammed the SMART value... I can confirm that when you use the "Offset" in Hard Disk Sentinel, then it performs only a "logical" clear of errors. It does not actually re-write the S.M.A.R.T. error counter inside the hard disk: by the Offset, you only acknowledged the problems in Hard Disk Sentinel exactly as you wrote: to prevent displaying the error (or triggering alarm) because you know what happened, you confirmed that you want to be notified only about possible new problems. The underflow happened inside the hard disk is completely different and the Offset has no effect in it. > What do you think? Is there a way to correct that wrong SMART stat report (besides simply offsetting)? Generally, the further testing you started is a good idea. Such problems can be very hard to reproduce, I only encountered very few times. In some of these cases simple usage (after long time) caused that the hard disk found out that there is no real weak sector, and the error counter can be zero. Intensive testing with Hard Disk Sentinel may make this more quick. But in some cases yes, the counter remain at 65535 even after long time, yes, in such case, the best is if you use offset -65535 as then the counter will be zero and no such value displayed again. | Теперь мне точно ясно, что Victoria здесь не причём, просто во время write + ddd произошёл некий програмный сбой в прошивке диска с двойным смещением значения 197 аттрибута, в итоге мы получили значение -1 в бинарном виде. Теперь вопрос, как вернуть нормальное значение. Да, вроде как в цитате написано на инглише как, но это как-то расплывчато. Цитата: Как я понял из ченч-лога последней версии, для автоматического ремапа софт-бэдов лучше по-прежнему использовать PE на WinXP? | Я вообще отрыл динозаврика в micro-itx, прикрутил импровизированный держатель для хардов, вывел наружу sata + питание и накатил x86 хрюшку)) Прям ненарадуюсь)) | Всего записей: 10 | Зарегистр. 05-09-2015 | Отправлено: 10:22 24-04-2019 | Исправлено: AndrewSE91, 10:27 24-04-2019 |
|