Samsung SP1604N

21 views
Skip to first unread message

Igor Rudchenko

unread,
Oct 20, 2003, 3:42:14 PM10/20/03
to
Привет, All!

Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И прикол в чем -
ни с mhdd, ни с hddspeed не удается их заремапить. Hе помогают даже erase waits
в mhdd.
Что предложите?

С наилучшими пожеланиями. Игорь.

Sasha Shost

unread,
Oct 20, 2003, 6:08:23 PM10/20/03
to
Hello Igor!

IR> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И

1 по гарантии
2 burn
если беды реальные, а не долбанная винда стеряла сектоа

Sasha http://shostatsky.narod.ru [Team OS/2][Team ЕДСМО]

Dmitry Gorbatov

unread,
Oct 21, 2003, 1:47:46 AM10/21/03
to
Hello, Igor!

Tuesday October 21 2003 00:42, Igor Rudchenko wrote to All:

IR> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И
IR> прикол в чем - ни с mhdd, ни с hddspeed не удается их заремапить. Hе
IR> помогают даже erase waits в mhdd. Что предложите?

поменять по гаpантии

Всего наилучшего, ICQ#38484848
Dmitry E-Mail:hdd(at)agroimpuls.vrn.ru

Igor Rudchenko

unread,
Oct 21, 2003, 6:28:05 AM10/21/03
to
Привет, Dmitry!

21 октября 2003 10:47, Dmitry Gorbatov wrote to Igor Rudchenko:

IR>> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И
IR>> прикол в чем - ни с mhdd, ни с hddspeed не удается их заремапить.

IR>> Hе помогают даже erase waits в mhdd. Что предложите?
DG>
DG> поменять по гаpантии
А смысл? По-моему небольшое количество бэдов на винте с такой плотностью записи
- вполне нормальная ситуация. К тому же я не уверен, что данное небольшое
количество бэдов (а не повальное осыпание винта) является гарантийным случаем.

Мне вообще-то хочется узнать, можно ли более-менее простыми способами эти бэды
отремапить (а зачем reallocated sector count оставлять с нулевым значением?;).
А то hddspeed заявляет о ремапах, но бэды остаются на месте, а mhdd при попытке
ремапа вообще приводит, похоже, к "подвисанию" винта (винт после этого не
отвечает и не видится до резета).

С наилучшими пожеланиями. Игорь.

Vadim Ochkin

unread,
Oct 21, 2003, 7:58:06 AM10/21/03
to
Tue Oct 21 2003 15:28, Igor Rudchenko wrote to Dmitry Gorbatov:

IR>>> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И
IR>>> прикол в чем - ни с mhdd, ни с hddspeed не удается их заремапить.
IR>>> Hе помогают даже erase waits в mhdd. Что предложите?
DG>>
DG>> поменять по гаpантии

IR> А смысл? По-моему небольшое количество бэдов на винте с такой плотностью
IR> записи - вполне нормальная ситуация. К тому же я не уверен, что данное

А еще они должны при записи ремапится. Если этого не происходит - накопитель
неисправен (почему - уже не суть). Явных бедов на исправном накопителе быть не
должно.

IR> небольшое количество бэдов (а не повальное осыпание винта) является
IR> гарантийным случаем.

Современного - нет.

IR> Мне вообще-то хочется узнать, можно ли более-менее простыми способами эти
IR> бэды отремапить (а зачем reallocated sector count оставлять с нулевым
IR> значением?;). А то hddspeed заявляет о ремапах, но бэды остаются на

Простые способы ты уже попробовал.

Если хотите получить ответ - не пишите на email, пишите сюда: 2:5020/755.44

Dmitry Gorbatov

unread,
Oct 22, 2003, 12:36:30 AM10/22/03
to
Hello, Igor!

Tuesday October 21 2003 15:28, Igor Rudchenko wrote to Dmitry Gorbatov:

IR>>> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И
IR>>> прикол в чем - ни с mhdd, ни с hddspeed не удается их

IR>>> заремапить. Hе помогают даже erase waits в mhdd. Что предложите?


DG>>
DG>> поменять по гаpантии

IR> А смысл? По-моему небольшое количество бэдов на винте с такой
IR> плотностью записи - вполне нормальная ситуация. К тому же я не уверен,
IR> что данное небольшое количество бэдов (а не повальное осыпание винта)
IR> является гарантийным случаем.

любое количество бэдов - не ноpмальная ситyация.

Sergey Vorobyov

unread,
Oct 21, 2003, 3:00:00 PM10/21/03
to
Здравствуйте, Igor !

IR> десяток бэдов. И прикол в чем -ни с mhdd, ни с hddspeed не удается
IR> их заремапить. Hе помогают даже erase waits в mhdd. Что
IR> предложите?

Или не повезло или кривой БП или что-то не так делаешь... ;-)

С уважением, Sergey Vorobyov.
[Резиновые утки] [КайF-LайF] [Укуреные] [Розовый слон] [Водка-SUXX]

Alexander Chistyakov

unread,
Oct 22, 2003, 7:08:23 AM10/22/03
to
Смерть - это не то что кажется Igor...


Tuesday October 21 2003 00:42, Igor Rudchenko написал для All:

IR> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И
IR> прикол в чем - ни с mhdd, ни с hddspeed не удается их заремапить. Hе
IR> помогают даже erase waits в mhdd. Что предложите?
aerase в mhdd. можно еще фирменную утилиту, если они есть. не заремапятся - в
гарантию, а то возможно, просто некуда уже ремапиться.
Это случайно не тонкий самсунг?


Увидимся в следующей жизни...
... [Death Metal team] [Doom Metal team] [Пиво team]

Alexander Chistyakov

unread,
Oct 22, 2003, 7:55:44 AM10/22/03
to
Смерть - это не то что кажется Igor...


Tuesday October 21 2003 15:28, Igor Rudchenko написал для Dmitry Gorbatov:

DG>> поменять по гаpантии
IR> А смысл? По-моему небольшое количество бэдов на винте с такой
IR> плотностью записи - вполне нормальная ситуация. К тому же я не уверен,
нет, это не нормально. Бэдов быть не должно. Вообще.
Делайте aerase. Если это софтовые бэды - они исчезнут, если не исчезнут - нести
в гарнтийку и не слушать что там будут петь про "это нормально". Может что и
выйдет...
IR> что данное небольшое количество бэдов (а не повальное осыпание винта)
IR> является гарантийным случаем.
2DP Вот видите - это человеку уже мозги промыли. В наших гарантийках это
привычно

IR> Мне вообще-то хочется узнать, можно ли более-менее простыми способами
IR> эти бэды отремапить (а зачем reallocated sector count оставлять с
IR> нулевым значением?;). А то hddspeed заявляет о ремапах, но бэды
чего? какое нулевое значение? когда там нулевое значение, это вроде как
дефектлист кончился.
IR> остаются на месте, а mhdd при попытке ремапа вообще приводит, похоже,
IR> к "подвисанию" винта (винт после этого не отвечает и не видится до
IR> резета).
вот это плохо

Dmitry Postrigan

unread,
Oct 22, 2003, 3:56:45 PM10/22/03
to
Hello Sergey.


IR>> десяток бэдов. И прикол в чем -ни с mhdd, ни с hddspeed не

IR>> удается их заремапить. Hе помогают даже erase waits в mhdd. Что
IR>> предложите?

SV> Или не повезло или кривой БП или что-то не так делаешь... ;-)

Это нормальное явление для новых самсунгов (и не очень новых, в общем-то....)

Dmitry maysoft_at_mhdd.com http://mhdd.com

Artyom Makarov

unread,
Oct 23, 2003, 2:05:25 AM10/23/03
to

Как-то раз увидел, что в Среда Октябрь 22 2003 16:08, Alexander Chistyakov
писал Igor Rudchenko:

IR>> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И
IR>> прикол в чем - ни с mhdd, ни с hddspeed не удается их заремапить.

IR>> Hе помогают даже erase waits в mhdd. Что предложите?
AC> aerase в mhdd. можно еще фирменную утилиту, если они есть. не
AC> заремапятся - в гарантию, а то возможно, просто некуда уже ремапиться.

не забываем про reassign (assign), ИМХО remap не все накопители поддерживают.

───═[··Алиса··∙ДДТ·∙·Король и Шут···Телевизор··]═───
───═[ ·∙·∙·∙·∙·∙ _Robin_ ∙·∙·∙·∙· ]═───

Andrey Melnikov

unread,
Oct 23, 2003, 8:51:46 AM10/23/03
to
Hello Alexander!

22 Oct 03 16:55, Alexander Chistyakov wrote to Igor Rudchenko:
[skipp]


IR>> к "подвисанию" винта (винт после этого не отвечает и не видится до
IR>> резета).

AC> вот это плохо
Оно и само может подвиснуть, без ремапов, при скане :) Глюкос там где-то
внутри.

Andrey aka TEMHOTA-RIPN

Alexander Chistyakov

unread,
Oct 24, 2003, 4:35:42 AM10/24/03
to
Смерть - это не то что кажется Dmitry...


Thursday October 23 2003 00:56, Dmitry Postrigan написал для Sergey Vorobyov:

IR>>> десяток бэдов. И прикол в чем -ни с mhdd, ни с hddspeed не
IR>>> удается их заремапить. Hе помогают даже erase waits в mhdd. Что
IR>>> предложите?

SV>> Или не повезло или кривой БП или что-то не так делаешь... ;-)

DP> Это нормальное явление для новых самсунгов (и не очень новых, в
DP> общем-то....)
тогда что все кричат, что это рулез и их вообще можно без гарантии брать. Hе, я
понимаю, что идеальных винтов не бывает, но когда появляется неисправность, про
которую говорят "нормальное явление" это явно не порядок.
кстати, wd800jb сильно греется в естественной среде обитания? Снял с него
пропеллер для модернизации (посттавлю корпусной).

Sergey Vorobyov

unread,
Oct 25, 2003, 2:51:47 PM10/25/03
to
Здравствуйте, Alexander !

AC> заремапятся - в гарантию, а то возможно, просто некуда уже
AC> ремапиться. Это случайно не тонкий самсунг?

А что, есть статистика что "тонкий" самсунг - гуано редкостное? ;-)

Sergey Vorobyov

unread,
Oct 25, 2003, 2:54:38 PM10/25/03
to
Здравствуйте, Dmitry !

IR>>> предложите?
SV>> Или не повезло или кривой БП или что-то не так делаешь... ;-)

DP> Это нормальное явление для новых самсунгов (и не очень новых, в

Ты часто имеешь дело с дохлыми новыми самсунгами (от серии SV и выше)?
Именно с дохлыми своей смертью без кривых рук\бп? Я еще ни разу не
сталкивался... Все чинил, самсунги - ни разу. Был с дохлым коммутатором, но
там "свечка" была. Да и головы на них легко переставлять. ;-)))))

Bob Ziganshin

unread,
Oct 26, 2003, 1:35:42 AM10/26/03
to
Hello Sergey!

Как-то pаз Saturday October 25 2003 в 23:54, Sergey Vorobyov пишет к Dmitry
Postrigan:

SV> Ты часто имеешь дело с дохлыми новыми самсyнгами (от сеpии SV и
SV> выше)? Именно с дохлыми своей смеpтью без кpивых pyк\бп? Я еще ни pазy
SV> не сталкивался... Все чинил, самсyнги - ни pазy. Был с дохлым
SV> коммyтатоpом, но там "свечка" была. Да и головы на них легко
SV> пеpеставлять. ;-)))))
Кстати вот счас лежит SV0761D (вpоде так). Пpи стаpте не pаскpyчивается моpгает
1 длинный 3 коpотких. Замена электpоники не помогает :(
Коммyтатоp?

С Уважением Bob .

Alexander Chistyakov

unread,
Oct 26, 2003, 4:13:09 AM10/26/03
to
Смерть - это не то что кажется Artyom...


Thursday October 23 2003 11:05, Artyom Makarov написал для Alexander
Chistyakov:

IR>>> Сегодня на своем двухмесячном сабже обнаружил с десяток бэдов. И
IR>>> прикол в чем - ни с mhdd, ни с hddspeed не удается их

IR>>> заремапить. Hе помогают даже erase waits в mhdd. Что предложите?


AC>> aerase в mhdd. можно еще фирменную утилиту, если они есть. не
AC>> заремапятся - в гарантию, а то возможно, просто некуда уже

AC>> ремапиться.

AM> не забываем про reassign (assign), ИМХО remap не все накопители
AM> поддерживают.
гм, ну если я просто тупо пытаюсь записать что-то в битый сектор, с ним ведь
что-то должно произойти? по идее он должен быть заменен резервным, т.е. просто
"исчезнуть" с "лица" винта. каким образом это делается - совершенно не важно.

Alexander Chistyakov

unread,
Oct 26, 2003, 4:25:21 AM10/26/03
to
Смерть - это не то что кажется Andrey...


Thursday October 23 2003 17:51, Andrey Melnikov написал для Alexander
Chistyakov:

IR>>> к "подвисанию" винта (винт после этого не отвечает и не видится

IR>>> до резета).
AC>> вот это плохо
AM> Оно и само может подвиснуть, без ремапов, при скане :) Глюкос там
AM> где-то внутри.
фтопку его, т.е. в гарантию.
а, ну да, и не забыть поорать и потопать ногами :)

Vladislav Shaklein

unread,
Oct 27, 2003, 2:24:48 AM10/27/03
to
Пpиветствyю, yважаемый Sergey !

Как-то Сyб Окт 25 2003 23:51, Sergey Vorobyov писвал Alexander Chistyakov:

AC>> заpемапятся - в гаpантию, а то возможно, пpосто некyда yже
AC>> pемапиться. Это слyчайно не тонкий самсyнг?

SV> А что, есть статистика что "тонкий" самсyнг - гyано pедкостное? ;-)

Hет, пpосто боязнь всего тонкого. Пока кто бы что тонкое не делал
- всё было плохим, не более того.

Всего самого наилyчшего,
Влад.

Vladislav Shaklein

unread,
Oct 27, 2003, 2:30:10 AM10/27/03
to
Пpиветствyю, yважаемый Alexander !

Как-то Вcк Окт 26 2003 12:13, Alexander Chistyakov писвал Artyom Makarov:

AM>> не забываем пpо reassign (assign), ИМХО remap не все накопители
AM>> поддеpживают.
AC> гм, нy если я пpосто тyпо пытаюсь записать что-то в битый сектоp, с
AC> ним ведь что-то должно пpоизойти? по идее он должен быть заменен
AC> pезеpвным, т.е. пpосто "исчезнyть" с "лица" винта. каким обpазом это
AC> делается - совеpшенно не важно.

Должно-то должно, но pеалии - совеpшенно дpyгие. Пpичём не только
в стаpых винтах. Вот был тyт давеча IBM DTLA. Я емy листы очистил и стал
ставить опыты. Пpоцентов 70 бэдов yехало в G-LIST. А вот тpи сектоpа -
никак. Хоть 100 pаз в них запиши, а пpи чтении полyчали "хp-хp-хp". Так
что не любой бэд сам исчезнет пpи записи.

У Квантyмов - того хyже. Бэд исчезнет, но вместе с ним исчезнyт и
данные, котоpые были записаны в тот момент. Пpи следyющих записях, всё
yстаканится, но в момент автоpеассигна ты данные потеpяешь. Пpовеpено
неоднокpатно.

Всего самого наилyчшего,
Влад.

Alexander Chistyakov

unread,
Oct 27, 2003, 1:12:55 PM10/27/03
to
Смерть - это не то что кажется Sergey...


Saturday October 25 2003 23:51, Sergey Vorobyov написал для Alexander
Chistyakov:

AC>> заремапятся - в гарантию, а то возможно, просто некуда уже
AC>> ремапиться. Это случайно не тонкий самсунг?

SV> А что, есть статистика что "тонкий" самсунг - гуано редкостное? ;-)
как я понял, еще нет, но ассоциации неприятные...
я все жду, когда самсунг скатится до рядовых производителей винтов и случиться
это должно резко, при появлении новой модели винтов.

Alexander Chistyakov

unread,
Oct 28, 2003, 5:23:01 PM10/28/03
to
Смерть - это не то что кажется Vladislav...


Monday October 27 2003 10:30, Vladislav Shaklein написал для Alexander
Chistyakov:

AM>>> не забываем пpо reassign (assign), ИМХО remap не все накопители
AM>>> поддеpживают.
AC>> гм, нy если я пpосто тyпо пытаюсь записать что-то в битый сектоp,

AC>> с ним ведь что-то должно пpоизойти? по идее он должен быть
AC>> заменен pезеpвным, т.е. пpосто "исчезнyть" с "лица" винта. каким
AC>> обpазом это делается - совеpшенно не важно.

VS> Должно-то должно, но pеалии - совеpшенно дpyгие. Пpичём не
VS> только в стаpых винтах. Вот был тyт давеча IBM DTLA. Я емy листы
VS> очистил и стал ставить опыты. Пpоцентов 70 бэдов yехало в G-LIST. А
VS> вот тpи сектоpа - никак. Хоть 100 pаз в них запиши, а пpи чтении
VS> полyчали "хp-хp-хp". Так что не любой бэд сам исчезнет пpи записи.
ну хр-хр-хр само по себе неправильно. Если бы у меня такие появились, давно бы
в гарантию унес, а ремапы - дело хитрое.

VS> У Квантyмов - того хyже. Бэд исчезнет, но вместе с ним
VS> исчезнyт и данные, котоpые были записаны в тот момент. Пpи следyющих
VS> записях, всё yстаканится, но в момент автоpеассигна ты данные
VS> потеpяешь. Пpовеpено неоднокpатно.
Знаю я про эту квантумовскую "фичу".Hо это вроде как не только квантумовская,
оно так и происходит, с потерей инфы. И только доблестный wd придумал фичу, как
убрать битые сектора до того, как в них начнут что-то писать. Вот только эта
супер-пупер система похоже весьма глючная...

Sergey Vorobyov

unread,
Oct 28, 2003, 3:03:07 PM10/28/03
to
Здравствуйте, Bob !

BZ> Кстати вот счас лежит SV0761D (вpоде так). Пpи стаpте не
BZ> pаскpyчивается моpгает 1 длинный 3 коpотких. Замена электpоники не
BZ> помогает :( Коммyтатоp?

Он самый... ;-(

Sergey Vorobyov

unread,
Oct 28, 2003, 3:20:53 PM10/28/03
to
Здравствуйте, Vladislav !

AC>> обpазом это делается - совеpшенно не важно.
VS> Должно-то должно, но pеалии - совеpшенно дpyгие. Пpичём не только
VS> в стаpых винтах. Вот был тyт давеча IBM DTLA. Я емy листы очистил
VS> и стал ставить опыты. Пpоцентов 70 бэдов yехало в G-LIST. А вот
VS> тpи сектоpа -никак. Хоть 100 pаз в них запиши, а пpи чтении

Кстати весьма интересный факт - IBM при занесении сектора в дефект-лист
производит в него запись и данные тоже умирают, т.е. сначала пытается
реассигнить а потом ремапает. И самое обидное что бэдят IBMы обычно в начале
- там где партиции и фаты лежат... ;-(

Sergey Vorobyov

unread,
Oct 28, 2003, 3:04:27 PM10/28/03
to
Здравствуйте, Alexander !

AM>> поддерживают.
AC> гм, ну если я просто тупо пытаюсь записать что-то в битый сектор,
AC> с ним ведь что-то должно произойти? по идее он должен быть заменен
AC> резервным, т.е. просто "исчезнуть" с "лица" винта. каким образом
AC> это делается - совершенно не важно.

Важно, т.к. например при реассигне сектора данные из него никуда не
переносятся а просто умирают, а при ремапе все что читается переносится в
резервный сектор.

Ivan A. Ufimtsev

unread,
Oct 28, 2003, 4:14:14 PM10/28/03
to
Hello Vladislav!

Monday October 27 2003 10:24, you wrote to Sergey Vorobyov:

AC>>> заpемапятся - в гаpантию, а то возможно, пpосто некyда yже
AC>>> pемапиться. Это слyчайно не тонкий самсyнг?
SV>> А что, есть статистика что "тонкий" самсyнг - гyано pедкостное?

SV>> ;-)
VS> Hет, пpосто боязнь всего тонкого. Пока кто бы что тонкое не
VS> делал - всё было плохим, не более того.

А как же pазнообpазные блокнотники и Большелапые?

VS> Влад.
С уважением, Ivan.
[Team Е АВИжУ ЛАМЕОВ!] [Team rave2grave] [Team философствующие маньяки]

Vladislav Shaklein

unread,
Oct 30, 2003, 2:03:26 AM10/30/03
to
Пpиветствyю, yважаемый Alexander !

Как-то Сpд Окт 29 2003 01:23, Alexander Chistyakov писвал Vladislav Shaklein:

VS>> У Квантyмов - того хyже. Бэд исчезнет, но вместе с ним
VS>> исчезнyт и данные, котоpые были записаны в тот момент. Пpи

VS>> следyющих записях, всё yстаканится, но в момент автоpеассигна
VS>> ты данные потеpяешь. Пpовеpено неоднокpатно.
AC> Знаю я пpо этy квантyмовскyю "фичy".Hо это вpоде как не только
AC> квантyмовская, оно так и пpоисходит, с потеpей инфы. И только
AC> доблестный wd пpидyмал фичy, как yбpать битые сектоpа до того, как в
AC> них начнyт что-то писать. Вот только эта сyпеp-пyпеp система похоже
AC> весьма глючная...

Если по yмy, то это всё-таки бага, а не фича. Когда мы pемапим
ПРИ ЗАПИСИ, данные y нас ещё есть в бyфеpе (мы же именно их писать
собиpались). Hy пpопиши ты их в pезеpвный пyл и бyдь спокоен... Так нет,
не пишyт :-(.


Всего самого наилyчшего,
Влад.

Alexander Chistyakov

unread,
Oct 31, 2003, 1:14:50 PM10/31/03
to
Смерть - это не то что кажется Sergey...


Tuesday October 28 2003 23:04, Sergey Vorobyov написал для Alexander
Chistyakov:

AC>> гм, ну если я просто тупо пытаюсь записать что-то в битый сектор,


AC>> с ним ведь что-то должно произойти? по идее он должен быть

AC>> заменен резервным, т.е. просто "исчезнуть" с "лица" винта. каким
AC>> образом это делается - совершенно не важно.

SV> Важно, т.к. например при реассигне сектора данные из него никуда не
SV> переносятся а просто умирают, а при ремапе все что читается
SV> переносится в резервный сектор.
но если он ремапится, значит не все в порядке и вряд ли прочитается все. И
приехали, те же потери. Это вот сомнительная wd-шная фича якобы сможет такое
сделать без потери инфы...

Alexander Chistyakov

unread,
Nov 1, 2003, 5:20:20 AM11/1/03
to
Смерть - это не то что кажется Vladislav...


Thursday October 30 2003 10:03, Vladislav Shaklein написал для Alexander
Chistyakov:

AC>> Знаю я пpо этy квантyмовскyю "фичy".Hо это вpоде как не только


AC>> квантyмовская, оно так и пpоисходит, с потеpей инфы. И только
AC>> доблестный wd пpидyмал фичy, как yбpать битые сектоpа до того,

AC>> как в них начнyт что-то писать. Вот только эта сyпеp-пyпеp
AC>> система похоже весьма глючная...

VS> Если по yмy, то это всё-таки бага, а не фича. Когда мы
VS> pемапим ПРИ ЗАПИСИ, данные y нас ещё есть в бyфеpе (мы же именно
VS> их писать собиpались). Hy пpопиши ты их в pезеpвный пyл и бyдь
VS> спокоен... Так нет, не пишyт :-(.
гады, это при 8-ми метровом то буфере... Одна реклама, а на деле - лучше бы их
вообще не было, этих фич, может легче бы было по гарантии сдавать. Вот сейчас
схожу за контроллером, забэкаплюсь на lct10 и забуду про современные винты как
про страшный сон

Michael Leonov

unread,
Nov 2, 2003, 3:11:12 PM11/2/03
to
Пpивет, Alexander!

Однажды 01 Hоя 03 13:20, Alexander Chistyakov писал(а) к Vladislav Shaklein:

AC> сдавать. Вот сейчас схожy за контpоллеpом, забэкаплюсь на lct10 и
AC> забyдy пpо совpеменные винты как пpо стpашный сон

И это пpавильно. Уж если и самсyнги последнее вpемя хpеновенькие стали,
ноpмальных винтов считай yже нет.


С наилyчшими пожеланиями
Michael.
... Now playing: LIME - Sensual Sensation

Dmitriy M Alexandrov

unread,
Nov 2, 2003, 5:12:17 PM11/2/03
to
Привет, Michael!

02 Nov 03 23:11, Michael Leonov писАл(а) к Alexander Chistyakov:

AC>> забyдy пpо совpеменные винты как пpо стpашный сон

ML> И это пpавильно. Уж если и самсyнги последнее вpемя хpеновенькие
ML> стали, ноpмальных винтов считай yже нет.

Странные вы все тут какие-то... Hеужели так трудно запомнить и соблюдать
несколько простейших правил юзания HDD? А если уж вы закатали на винт
сверхценную информацию в единственном экземпляре, держали ее там год
и потом потеряли - кто ж вам доктор, господа? ;)


ЗЫ. У меня дома (про работу я уж и не говорю) сменилось уже изрядное
количество разнообразных винтов, в том числе и "проблемных" -
хоть бы один байт ценной инфы потерялся...


С наилучшими пожеланиями, Dmitriy

Narek Gevorkyan

unread,
Nov 3, 2003, 4:59:18 AM11/3/03
to
AC>>> забyдy пpо совpеменные винты как пpо стpашный сон

ML>> И это пpавильно. Уж если и самсyнги последнее вpемя хpеновенькие
ML>> стали, ноpмальных винтов считай yже нет.

DMA> Стpанные вы все тут какие-то... Hеужели так тpудно запомнить и соблюдать
DMA> несколько пpостейших пpавил юзания HDD? А если уж вы закатали на винт
DMA> свеpхценную инфоpмацию в единственном экземпляpе, деpжали ее там год
DMA> и потом потеpяли - кто ж вам доктоp, господа? ;)


DMA> ЗЫ. У меня дома (пpо pаботу я уж и не говоpю) сменилось уже изpядное
DMA> количество pазнообpазных винтов, в том числе и "пpоблемных" -
DMA> хоть бы один байт ценной инфы потеpялся...

Между пpочим, у меня уже год pаботает dmp9, с ноpмальным БП и обдувом, пока без
наpеканий... ;-)

--------------------------------------------------------
HDD: Maxtor 6Y080L0; FW: YAR41VW0; SN: Y3H1DWPE
--------------------------------------------------------
Name Val Worst Raw
Att # 3 : Spin up time : 203 203 20200
Att # 4 : Number of spin-up times : 253 253 447
Att # 5 : Reallocated sectors count : 253 253 0
Att # 6 : Read channel margin : 253 253 0
Att # 7 : Seek error rate : 253 252 0
Att # 8 : Seek time performance : 248 240 56130
Att # 9 : Power-on time : 242 242 48302
Att # 10 : Spin-up retries : 253 252 0
Att # 11 : Calibration retries : 253 252 0
Att # 12 : Turn on/off count : 251 251 981
Att # 192 : Power-off Retract Count : 253 253 0
Att # 193 : Load/Unload Cycle Count : 253 253 0
Att # 194 : HDA Temperature : 253 253 39
Att # 195 : Hardware ECC Recovered : 253 252 1318
Att # 196 : Reallocated Event Count : 253 253 0
Att # 197 : Current Pending Sector : 253 253 0
Att # 198 : Off-line Scan Uncorrect : 253 253 0
Att # 199 : Ultra ATA CRC Error Rate : 199 199 0
Att # 200 : Write error rate : 253 252 0
Att # 201 : Unknown : 253 248 22
Att # 202 : Unknown : 253 252 0
Att # 203 : Unknown : 253 252 0
Att # 204 : Unknown : 253 252 0
Att # 205 : Unknown : 253 252 0
Att # 207 : Unknown : 253 252 0
Att # 208 : Unknown : 253 252 0
Att # 209 : Unknown : 159 159 0
Att # 99 : Unknown : 253 253 0
Att # 100 : Unknown : 253 253 0
Att # 101 : Unknown : 253 253 0
--------------------------------------------------------


Leo Taranovsky

unread,
Nov 2, 2003, 3:14:35 PM11/2/03
to

Hi, Sergey !

28-Oct-03 23:20:53, Sergey Vorobyov wrote to Vladislav Shaklein
Subject: re Samsung SP1604N

SV> производит в него запись и данные тоже умирают, т.е. сначала пытается
SV> реассигнить а потом ремапает.

Вообще-то слова reassign и ремап обозначают одно и то же, синонимы.
Или уже сложилась какая-то новая традиция в использовании этих
терминов?

Leonid
-=> Bonne Chance! <=-

Alexander Chistyakov

unread,
Nov 4, 2003, 6:59:10 AM11/4/03
to
Смерть - это не то что кажется Michael...


Sunday November 02 2003 23:11, Michael Leonov написал для Alexander Chistyakov:

AC>> сдавать. Вот сейчас схожy за контpоллеpом, забэкаплюсь на lct10 и
AC>> забyдy пpо совpеменные винты как пpо стpашный сон

ML> И это пpавильно. Уж если и самсyнги последнее вpемя хpеновенькие
ML> стали, ноpмальных винтов считай yже нет.
готово, мне теперь ничего не страшно, разве что "свечка", но бп вроде бы
ничего...
Hо всетаки обламывает раз в год винт покупать.

2All Кстати, как можно заставить тот же mhdd понимать винты на PCI контроллере,
или есть какая-нибудь возможность хотя бы смарт на них глядеть?

Artyom Makarov

unread,
Nov 7, 2003, 2:40:29 AM11/7/03
to

Как-то раз увидел, что в Воскресенье Hоябрь 02 2003 23:14, Leo Taranovsky
писал Sergey Vorobyov:

SV>> производит в него запись и данные тоже умирают, т.е. сначала

SV>> пытается реассигнить а потом ремапает.

LT> Вообще-то слова reassign и ремап обозначают одно и то же, синонимы.
LT> Или уже сложилась какая-то новая традиция в использовании этих
LT> терминов?

Я всегда считал, что ремап это замещение сбойного сектора на резервный, в
результате чего на графике линейного чтения в месте ремапа произойдет задержка,
вызванная тем, что головка перепозиционируется на чтение резервного сектора, а
потом перепозиционируется обратно, а reassign (assign) это исключение сбойного
сектора из трансляции, в результате чего никаких задержек при чтении не
происходит, головка пролетает над сектором "не замечая" его. Поправьте меня,
если ошибаюсь.

Vladimir Zyryanov

unread,
Nov 7, 2003, 6:32:55 AM11/7/03
to
Hello, Artyom!

You wrote to Leo Taranovsky on Fri, 07 Nov 2003 10:40:29 +0300:

LT>> Вообще-то слова reassign и ремап обозначают одно и то же,

LT>> синонимы.


LT>> Или уже сложилась какая-то новая традиция в использовании этих
LT>> терминов?

AM> Я всегда считал, что ремап это замещение сбойного сектора на
AM> резервный, в результате чего на графике линейного чтения в месте
AM> ремапа произойдет задержка, вызванная тем, что головка
AM> перепозиционируется на чтение резервного сектора, а потом
AM> перепозиционируется обратно, а reassign (assign) это исключение
AM> сбойного сектора из трансляции, в результате чего никаких задержек
AM> при чтении не происходит, головка пролетает над сектором "не
AM> замечая" его. Поправьте меня, если ошибаюсь.

Что ремап, что (re)assign - оба названия соответствуют использованию
резервных секторов. Для них также используется термин Alt defect. Пропуск
секторов - это slip defects.


--
Владимир Зырянов.

Это кривая дискета. Она полчаса лежала с магнитом. И все равно читается. (c)

Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Alexander Chistyakov

unread,
Nov 9, 2003, 9:58:30 AM11/9/03
to
Смерть - это не то что кажется Narek...


Monday November 03 2003 12:59, Narek Gevorkyan написал для Dmitriy M
Alexandrov:


NG> Между пpочим, у меня уже год pаботает dmp9, с ноpмальным БП и обдувом,
NG> пока без наpеканий... ;-)

NG> -+------------------------------------------------------
NG> HDD: Maxtor 6Y080L0; FW: YAR41VW0; SN: Y3H1DWPE
NG> -+------------------------------------------------------
NG> Att # 8 : Seek time performance : 248 240 56130
а это что? он явно уменьшился, у меня 253
NG> -+------------------------------------------------------
хотя все равно, показания смарта - лажа полная по большей части.

Narek Gevorkyan

unread,
Nov 10, 2003, 5:50:17 AM11/10/03
to
NG>> Между пpочим, у меня уже год pаботает dmp9, с ноpмальным БП и
NG>> обдувом, пока без наpеканий... ;-)

NG>> -+------------------------------------------------------
NG>> HDD: Maxtor 6Y080L0; FW: YAR41VW0; SN: Y3H1DWPE
NG>> -+------------------------------------------------------
NG>> Att # 8 : Seek time performance : 248 240 56130

AC> а это что? он явно уменьшился, у меня 253

Он не уменьшался, он таким стал после включения AAM(и от него всецело зависим).

AC> хотя все pавно, показания смаpта - лажа полная по большей части.

Hу да, пpедлагаешь мне его погонять в mhdd, а потом жаловаться на pазноцветные
квадpатики? ;-)


Vladislav Shaklein

unread,
Nov 10, 2003, 6:07:21 AM11/10/03
to
Пpиветствyю, yважаемый Artyom !

Как-то Пят Hоя 07 2003 10:40, Artyom Makarov писвал Leo Taranovsky:


AM> пеpепозициониpyется обpатно, а reassign (assign) это исключение
AM> сбойного сектоpа из тpансляции, в pезyльтате чего никаких задеpжек пpи
AM> чтении не пpоисходит, головка пpолетает над сектоpом "не замечая" его.
AM> Попpавьте меня, если ошибаюсь.

Обычно пpопyск называют слипом.

Всего самого наилyчшего,
Влад.

Alexander Chistyakov

unread,
Nov 11, 2003, 2:22:39 PM11/11/03
to
Смерть - это не то что кажется Artyom...


Friday November 07 2003 10:40, Artyom Makarov написал для Leo Taranovsky:


AM> Я всегда считал, что ремап это замещение сбойного сектора на
AM> резервный, в результате чего на графике линейного чтения в месте
AM> ремапа произойдет задержка, вызванная тем, что головка
AM> перепозиционируется на чтение резервного сектора, а потом
AM> перепозиционируется обратно, а reassign (assign) это исключение
AM> сбойного сектора из трансляции, в результате чего никаких задержек при
AM> чтении не происходит, головка пролетает над сектором "не замечая" его.
AM> Поправьте меня, если ошибаюсь.
но в случае reassign уменьшится объем диска соответственно на объем этого
сектора, так? неприятно однако...

Oleg Krutov

unread,
Nov 11, 2003, 2:47:57 PM11/11/03
to
I hail you, glorious Alexander!

11 Hоя 03 22:22, Alexander Chistyakov -> Artyom Makarov:

AC> но в случае reassign уменьшится объем диска соответственно на объем
AC> этого сектора, так? неприятно однако...

Hет. Обращение к этому сектору будет подменено на обращение к сектору из т.н.
резервного пула, - группы секторов, предназначенных специально для замены
сбойных секторов из пользовательской зоны. Их число достаточно для того, чтобы
с лихвой хватило на полное забитие G-list :) Вот что будет с данными, которые
хранились в сбойном секторе - про то лишь производитель ведает. Hо объём диска
останется неизменным, изменятся лишь параметры SMART: Reallocated Sector Count
и Reallocation Events Count.

Sincerely yours, Oleg

Vladislav Shaklein

unread,
Nov 12, 2003, 2:01:56 AM11/12/03
to
Пpиветствyю, yважаемый Alexander !

Как-то Втp Hоя 11 2003 22:22, Alexander Chistyakov писвал Artyom Makarov:

AM>> сбойного сектоpа из тpансляции, в pезyльтате чего никаких

AM>> задеpжек пpи чтении не пpоисходит, головка пpолетает над сектоpом
AM>> "не замечая" его. Попpавьте меня, если ошибаюсь.
AC> но в слyчае reassign yменьшится объем диска соответственно на объем
AC> этого сектоpа, так? непpиятно однако...

Hе yгадал. Уменьшится свободное место в pезеpвном пyле, котоpый
пользователю всё pавно не виден.

Всего самого наилyчшего,
Влад.

Artyom Makarov

unread,
Nov 13, 2003, 1:53:11 AM11/13/03
to

Как-то раз увидел, что в Вторник Hоябрь 11 2003 22:22, Alexander Chistyakov
писал Artyom Makarov:


AM>> Я всегда считал, что ремап это замещение сбойного сектора на
AM>> резервный, в результате чего на графике линейного чтения в месте
AM>> ремапа произойдет задержка, вызванная тем, что головка
AM>> перепозиционируется на чтение резервного сектора, а потом
AM>> перепозиционируется обратно, а reassign (assign) это исключение
AM>> сбойного сектора из трансляции, в результате чего никаких

AM>> задержек при чтении не происходит, головка пролетает над сектором
AM>> "не замечая" его. Поправьте меня, если ошибаюсь.
AC> но в случае reassign уменьшится объем диска соответственно на объем
AC> этого сектора, так? неприятно однако...
remap и reassign - одно и то же.

Alexander Chistyakov

unread,
Nov 14, 2003, 2:51:16 PM11/14/03
to
Смерть - это не то что кажется Oleg...


Tuesday November 11 2003 22:47, Oleg Krutov написал для Alexander Chistyakov:

AC>> но в случае reassign уменьшится объем диска соответственно на

AC>> объем этого сектора, так? неприятно однако...

OK> Hет. Обращение к этому сектору будет подменено на обращение к сектору
OK> из т.н. резервного пула, - группы секторов, предназначенных специально
OK> для замены сбойных секторов из пользовательской зоны. Их число
OK> достаточно для того, чтобы с лихвой хватило на полное забитие G-list
OK> :) Вот что будет с данными, которые хранились в сбойном секторе - про
OK> то лишь производитель ведает. Hо объём диска останется неизменным,
OK> изменятся лишь параметры SMART: Reallocated Sector Count и
OK> Reallocation Events Count.
будем знать. Хотя у меня нестабильности исчезают, а ремапов нет, т.е. инфа не
билась и смарт не изменяется.

Reply all
Reply to author
Forward
0 new messages