проверка диска с перезаписью в фоне

Для того чтобы HDD своими методами проверил и переназначил в случае надобности битый сектор нужно произвести запись
badblock -w не умеет этого делать в фоне, да и диск затирает

есть ли утилиты умеющие это делать в фоне(без необходимости отмонтировать диск) и без разрушения информации?
https://wiki.archlinux.org/index.php/Identify_damaged_files#Force_the_disk_to_reallocate_bad_block

А какие проблемы?
смарт тест не проходит
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%     47800         185709388
# 2  Extended offline    Completed: read failure       90%     47795         185709388
# 3  Short offline       Completed: read failure       10%     47795         185709388
# 4  Extended offline    Completed without error       00%     41008         -
# 5  Short offline       Completed without error       00%     40435         -
# 6  Short offline       Completed without error       00%     39299         -
# 7  Short offline       Completed without error       00%     39094         -
# 8  Short offline       Completed without error       00%     35888         -
# 9  Short offline       Completed without error       00%     35396         -
#10  Short offline       Completed without error       00%     28877         -
#11  Short offline       Completed without error       00%     27768         -
#12  Short offline       Completed without error       00%     27768         -
#13  Short offline       Completed without error       00%     27768         -
#14  Short offline       Completed without error       00%     21465         -
#15  Short offline       Completed without error       00%     20821         -
#16  Short offline       Completed without error       00%     20408         -
#17  Short offline       Completed without error       00%     20232         -
#18  Extended offline    Completed: read failure       80%     20229         208692538
#19  Short offline       Completed without error       00%     19782         -
как видно ранее подобное было, но исчезало, только не помню после чего, виктории наверно или mhdd

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       1
Четыре блока не много. Можно попробовать переписать нулями чтобы заменить сектор, но если ошибетесь или сектор на данных потеряете информацию
инструция
https://www.alexeykopytko.com/2018/smartctl-dd/
нулями - это с возможной потерей, не вариант

в моём понимании алгоритм софтины должен быть таким:
1. считывает сектор(ы) и запоминает его содержимое
2. пишет в него с последующей проверкой 1010, 0101 и т.п. маски, если ошибка - вывести инфу
3. восстанавливает исходные данные сохранённые в шаге №1
4. следующий сектор(ы)
grayich
алгоритм софтины должен быть таким
Не слышал про такую , может Vasek что подскажет или еще кто то

Вариант забить не подходит?
Если на сбойный сектор запись попадет он автоматом переназначится, а если на нем данные то им и так уже ...
vs220
Четыре блока не много.
Согласен, году в 2010-м купил винт на 500 гиг, gnome-disk-utility показала 128 перемещенных секторов, винт давно продан, стоит у человека, и все так же показывает 128.
In Tux We Trust
неужели не существует человеческой утилитки для вычисления файла по его LBA ?

бо вручную вычислять например так - не прикольно
grayich
есть ли утилиты умеющие это делать в фоне(без необходимости отмонтировать диск) и без разрушения информации?
Эти утилиты вообще не нужны. Современные HDD - это миникомпьютеры и все что нужно они это делают сами.
В части bad блоков - при неустойчивом чтении сектора, или же ошибки его чтения, SMART заносит его в список нестабильных и увеличит их счетчик (Current_Pending_Sector). Если при повторном обращении сектор будет прочитан без проблем, он будет выброшен из этого списка. Если же нет, то при представившейся возможности - при отсутствии обращений к диску, диск начнет самостоятельную проверку поверхности, в первую очередь подозрительных секторов. Если сектор будет признан сбойным, то он будет переназначен на сектор из резервной поверхности. Такое фоновое переназначение приводит к тому, что на современных винчестерах сбойные секторы практически никогда не видны при проверке поверхности сервисными программами. HDD имеет два дефект-листа P-list (Primary, заводской) и G-list (Growth, формируется непосредственно во время эксплуатации). И при большом числе переназначений может оказаться так, что в G-list не оказывается места для записи о новом переназначении. Эта ситуация может быть выявлена по высокому показателю переназначенных секторов в SMART.

Что от юзера требуется, то это определить какие функции поддерживает его HDD, проверить активирована ли функция SMART, при необходимости настроить автопроверку. Но луше делать это в ручную, минимум 1 раз в полгода/год, в зависимости от состояния HDD и динамического изменения основных параметров. И рекомендую сохранять периодически выводы smartctl -A /dev/sda, чтобы отслеживать динамику.
Привожу вывод в части bad блоков своего HDD после 8 лет эксплуатации
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
   5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always          -       51
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always    -       3
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always     -       0

В части появления bad блоков в выводе self-test, точнее в столбце LBA_of_first_error - теоретически, этот блок должен быть переназначен, но не всегда все так просто - не буду расписывать, а приведу расширенную выдержку из документации
Those sorts of problems are sometimes caused by magnetic regions that just spontaneously "go bad". But they are more often caused by hard contact between the flying heads and the surface of the rapidly-spinning platters. This can be a contact so severe that it sprays magnetic debris from the platters inside the quasi-sealed portion of the drive. This turns what was a "near clean room" environment into an area strewn with magnetic dust.
Data is stored using a semi-redundant code (from a class of codes called Hamming codes) that allow the drive controller to do error correction for small bursts of errors in a block. If the block cannot be corrected, it is retried, and retried, and retried (dozens to hundreds of times) before the controller gives up and adds it to the possible bad blocks list. Since the correct data for that block are unknown (since the block cannot be read and corrected) the drive cannot do anything more about it until you supply new data to be written to the block.
When you supply new data for a block on the possible bad blocks list, the controller holds onto the data, writes it to the block, and checks for a read with no correction needed. IF the new data "sticks", the block is not permanently bad. If the new data cannot be read back without correction (or at all) immediately after being written, the block is declared permanently bad and the controller writes the retained data to a spare block and makes a permanent substitution.
В таких случаях желательно провести дополнительный анализ bad блока для потдвержения ошибки используя hdparm.
В принципе в документации описано несколько вариантов решения данной проблемы, но не привожу - есть опасность при неправильном выполнении.
UPD - правда можно переназначить bad блок используя fsck - есть такая опция, но никогда не использовал. Но лучше, наверное, сделать запись в этот блок, используя hdparm

grayich
неужели не существует человеческой утилитки для вычисления файла по его LBA ?
В таких случаях надежнее считать ручками, слишком много нужно объяснять утилите - размер сектора HDD, размер сектора/блока файловой структуры (это разные понятия), плюс к этому расположение разделов на диска и др. А цена ошибки здесь слишком большая. Да в принципе это и считается довольно просто, к тому же очень редко требуется.

EDIT 1 - а вообще в таких случаях или ждут, пока HHD перестанет упрямится и переназначит данный блок, или делают эту вручную, используя dd или hdparm
Ошибки не исчезают с опытом - они просто умнеют
grayich
бо вручную вычислять например так - не прикольно
И зачем тут утилита?
Высчитать один раз и так пойдет.
А если не один, то сложно команды в скрипт сложить?
Lupus pilum mutat, non mentem.
 
Зарегистрироваться или войдите чтобы оставить сообщение.