inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот
Ничего подобного. У вас всего ~37000 парковок. Для ноутбучного диска наработавшего ~45000 часов - нормально. Проблемы скорее могли быть вызваны ударами, вибрациями, резкими движениями. Аж 83 случая зафиксировано по превышению допустимых ускорений. (191-ый параметр).
Диск ноутбучный, для них частые парковки - норма и необходимость. Это защита от внешних воздействий, без нее ноутбучные диски бы жили в среднем по 3-5 месяцев.
Обычно видно при детальном рассмотрении. Может головка задевает блины. Или еще что-то подобное.
Имею ввиду, что может что-то отвалилось, и по пластинам гуляет.
Еще не до конца изучил значения показателей smart, то есть какие пункты показывают бэды. Но мне кажется, что у меня их не так много. Точно не 100%, и даже не 50%. Значит надежда есть.Griga211 писал(а): ↑20 ноя 2018, 22:19Ну там может быть что угодно. У меня лежит 2 диска, один умер после падения со стола, другой после 7-лет работы то ли от удара кулаком по ноуту, то ли просто от старости. Повреждения на них 100% физические: первый - почти 100 % поверхности диска не читается. Даже низкоуровневое форматирование не запускается, т.к. он не может считать информациюю из нулевого сектора. Либо проблема контроллера, либо головки, думаю второе. Второй диск не читается в начале и в конце. Повреждены скорее всего головки первого и последнего блина, а средние читаются, но бэды присутствуют. Можно пространство с бэдами вырезать из таблицы и создать разделы на средних блинах, но боюсь он уже все равно долго не протянет.
Это я понимаю. Я имел ввиду, что если диск пойдет на помойку, то я его точно разберу. Посмотрю как он устроен, и в каком он состоянии. Если будет возможность, то разобрал бы и диски других производителей, чтобы сравнить насколько качественно они выглядят внутри. По статистике у Seagate больше всех отказов дисков, меньше всего у HGST.slant писал(а): ↑20 ноя 2018, 22:29Современные диски нельзя разбирать. Там стерильность. Единственная микронная пылинка прошедшая через фильтр спец-канала который служит для выравнивания давления как раз и может привести к тому, что диск "посыпется". Слышали про "синдром Кесслера" относительно аварий спутников и космического мусора? Вот с дисками та же история. Пылинка попадая на диск вращающийся на огромной скорости выбивает из поверхности еще одну микрочастицу, так в свою очередь еще - и по нарастающей. Плюс, головка парит над диском на микронных высотах, и попавшая под нее частица может сработать как резец в токарном станке.
Это нормально. ПК же не все время работал. когда то и выключался, да даже если и нет, то это нормальный показатель.
Ничего подобного. В какой то степени наоборот, линукс с файловой системой ext4 меньше нагружает диск, по сравнению с windows и ntfs, с их постоянной фрагментацией и дефрагментацией. Тут побольше части все зависит от логики работы планировщика.
Одно время я его вообще не отключал, неделями. У некоторых бывает всего несколько тысяч парковок за несколько лет, у других за год под 100 000.
Спорное утверждение. Я не сторонник Windows, но диски в ней дольше держатся. NTFS кстати надежней. Я очень небрежно обращался с дисками, когд винда была. Но они держались долго, и если были неполадки обычно виндовый chkdsk (или как там его) помогал. Не так давно внешний диск перестал определяться, провел сканирование на винде, и все нормально стало.
Я привел не свою статистику, а Backblaze https://habr.com/post/409921/.
Еще раз повторяю - диск ноутбучный. Для них это норма. Даже парковка раз в 15 минут для ноутбука норма. Бить тревогу следует, если парковка происходит несколько раз в минуту. По сути, такое состояние по парковкам даже для десктопа было бы приемлемым. А нотбучный винт так защищается от внешних воздействий на ноутбук, что куда опаснее для него.
У вас их офигеть как много. 5-ый параметр - это только подтвержденные на 100% и с выполненным ремапом. Диск, где их хотя бы 10 - это уже ненадежный диск, даже если все остальное в норме. У вас их 215! Скорее всего лимит по ремапам выбран полностью. (Для ремапа используется сектор вне основного пула, их совсем не бесконечное количество, а где-то 100-300 как раз, от модели зависит).
Сектор же занимает 512 байт. Получается около 100Мб бэдов, из 750Гб общей емкости.
Чем можно пофиксить софт-бэды?
Вы путаете программные и аппаратные проблемы. chkdsk ничего не может сделать с аппаратными бэдами, раз помог - проблемы были программные, с самой файловой системой. Что совсем не в пользу ее надежности говорит.srmcbtxf писал(а): ↑20 ноя 2018, 22:59Спорное утверждение. Я не сторонник Windows, но диски в ней дольше держатся. NTFS кстати надежней. Я очень небрежно обращался с дисками, когд винда была. Но они держались долго, и если были неполадки обычно виндовый chkdsk (или как там его) помогал. Не так давно внешний диск перестал определяться, провел сканирование на винде, и все нормально стало.
Происходило копирование, а в это время свет отключили.
Это я знаю, мне ничего не помогало, поэтому и пришлось искать машину с виндой, чтобы диск восстановить.
У вас неверное представление о remap. Он не использует другие произвольные сектора диска. Специально для ремапа производитель добавляет небольшой пул нигде более не используемых секторов. Этот лимит - 100-300 секторов обычно, от производителя и модели зависит.
Перезаписью. Любая перезапись сектора уберет софт-бед. Т.к. оный - всего лишь несовпадение контрольной суммы. Но данные там при этом будут потеряны все равно. Беда тут в том, что если софтбэдов такое дикое количество - это говорит о проблемах головки. Т.е. она не может правильно прочитать/записать секторы. Случайных софт-бедов, для положительного прогноза может быть в пределах сотни, не более. "Естественный" механизм их образования без далеко идущих последствий - в момент записи пропало питание, или случился внешний толчок/рывок и сбил головку с позиции над дорожкой.
Я не про ремап, а про то, что "бэдов офигеть как много". Разве много 100Мб из 750Гб.
Это и есть чисто программные проблемы - повреждение структур метаданных. Классическое.
Но у нее свои тараканы. У них свои проблемы. Но именно таких - нету конечно. Однако в целом - hdd вроде бы как пока несколько надежнее. И еще - ssd имеют тенденцию умирать разом. Тогда как hdd - во многих случаях дают время вытащить данные, если вовремя спохватились.
Это в теории, а на практике как? Я же не буду весь диск перезаписывать чем попало. Может утилиты есть какие? Форматирование значит не поможет?
Я же писал про "Синдром Кесслера" и процессе "осыпания" диска. Если у вас только 100% подтвержденных проблем поверхности аж 215...
Смотря какое. Быстрое - нет (т.к. поверхность давно не проверяется при этом). А забитие раздела / диска нулями - вполне. Скажем через dd:
dd if=/dev/zero of=/dev/диск_или_раздел bs=1M !!! Не делать из интереса - уничтожает данные, подтверждения не спрашивает !!!
Попробую, когда данные выловлю все. Сейчас даже скопировать некуда.
Физические бэды же можно пометить, чтобы в дальнейшем туда не писалось ничего? Нормальных секторов же еще уйма. Как понять какие проблемы с головкой?slant писал(а): ↑20 ноя 2018, 23:48Я же писал про "Синдром Кесслера" и процессе "осыпания" диска. Если у вас только 100% подтвержденных проблем поверхности аж 215...
А еще проблемы с головкой - т.е. абсолютно любая операция и в любой момент может оказаться невыполнимой, или пройти с ошибкой/случайным искажением. Что для ext4 что для ntfs - это беда, если придется на момент записи в метаданные. Тут даже btrfs не особо спасет, хотя скорее всего выдержит дольше.
Считайте что их уже нет. Особенно по причине см. ниже. Ну и из-за того что оно именно сыпется. А так - smart делает remap и помечает их автоматически. Если возможности по ремапу исчерпаны - на такое конструкторы не рассчитывали.
Какая разница какие? Это вообще не лечится, даже в сервисе. Главное что они есть, т.е. нет гарантии что записано или прочитано будет именно то, что должно было быть. Случайные искажения данных. Как понять что они вообще есть - я написал в предыдущих сообщениях. Параметр в смарт показывает.
подождите, я не про ремап, или я неправильно понимаю что-то. Предположим резервных секторов нет, можно при этом заставить диск не использовать битые сектора? Любым способом, чтобы он не записывал туда ничего, как будто их нет вообще. Читал статью на хабре, что как то можно юзать только хорошие сектора.
Нет. Нельзя. Нету такого функционала у дисков. Когда-то очень давно такой функционал был у самих OS и файловых систем - это делалось при форматировании. В те времена битый сектор был практически рядовым явлением, у меня, например, в 90-ых был 10 мегабайтный диск, который показывал от 200 до 300 битых секторов при форматировании и нормально (относительно) работал потом. Размером был с два 5 дюймовых дисковода (сидюка - если не застали их
). Но с ростом надежности, битый физический сектор, даже ОДИН(!) стал поводом сдать диск в гарантию, или приготовится к замене (если не новый). Процесс форматирования свелся с к проверке поверхности чтением, и сообщении о проблемах, если они найдены (а еще позже и это убрали по умолчанию - остался только процесс создания начальной структуры метаданных) А смарт взял на себя всю заботу о механике дисков, маскируя случайные единичные битые сектора ремапом.
Вручную утомительно такое действо. Скорее всего кто-то написал для этого утилиту. Почему не мой случай?slant писал(а): ↑21 ноя 2018, 01:31Сейчас, если местоположение битых секторов фиксировано, и их количество не меняется (т.е. диск не сыпется) и в остальном исправен, можно вручную вычислить их место и сделать разбивку диска на разделы так, чтобы место с битыми секторами не попало внутрь разделов, и соответственно не использовалось. Но это не ваш случай.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя