Возможно ли как-то выдрать количество уже просканированных блоков, чтобы запустить завтра продолжение?

Насколько я знаю, нет. Тоже много возился со старыми айбиэмовскими хардами, так у них было столько бэдов, что проще выкинуть.
Просто не выключай комп пару дней.

Полторашный диск должен сканироваться часа четыре. Если он хочет это делать в течение трёх суток, значит ему на свалку пора.

И посмотрите уже ман, там в первом же абзаце есть ответ.

Полторашный диск должен сканироваться часа четыре

Ты бы прикинул вначале: операция записи + операция чтения == ~25МБ/с. В час это ~88ГБ, в сутки ~2ТБ. Но у меня медленный старый диск, там скорость ~10МБ/с, сейчас имею:

1.04% done, 49:23 elapsed

это где-то 3.4 суток.

Про first-block в мане прочитал. В первый раз что-то я на это внимания не обратил. Но вот как узнать, на каком блоке сейчас идет сканирование? Или тупо взять этот процент, да умножить на общее кол-во блоков?

Если сканировать только на чтение, то он должен выдавать сотню. Старый? Хорошо, пусть выдаёт полтинник. Если меньше, то это не диск, а тормоз.

Вот тут ничего не могу сказать. Если с опцией -s он не выдаёт номер блока, то остаётся разве что сканировать по частям, т.е. сначала от блока 1 до N, потом от N до 2N и т.д.

Решето!

Я же сканирую на запись-чтение, чтобы надежно. Старый — ему года три уже! Обычно больше четырех-пяти лет жесткие диски не живут (по крайней мере, три предыдущих сдохли после 4-5 лет службы). Полтинник физически ни один жесткий SATA диск не может выдать — это же не SSD!

Но я понял, как статус сохранять (заодно, почитав маны, врубился, что размер блока надо было сразу делать 4096 — перезапустил, установив правильный размер и разделив количество просканированных блоков на 4, чтобы определить номер первого блока для сканирования).

Когда badblocks получает SIGINT, он пишет, на каком блоке вырубился, например:

Interrupted at block 4519600

badblocks /dev/sdg1 -b 4096 -svw -o sdg1-bads 1465136127 4519600

Всё равно что-то уж слишком медленно. У меня системный диск даже при копировании файла на самого себя 30-35 выдаёт.

Полторашный диск должен сканироваться часа четыре

Все, поздравляю, ты заслужил плашку «ламер».
Бэдблокс делает четыре прохода, каждый из одного прохода полной записи и одного прохода проверки записанного.
Потому даже самая быстрая полторашка будет тестироваться около 15-18 часов.

Спасибо, я старался.

А на чтение она тестируется 4 часа.

Тестировать «на чтение» тоже будет только ламер, ибо тестировать оно ничего не тестирует :)

Ага, автору делать нечего было, он и решил бесполезную проверку написать. Для галочки.

P.S. вы зря стараетесь вывести меня из себя и получить предложение отправиться в пешее эротическое. Я разве что под мост могу послать или в игнор.

вы зря стараетесь вывести меня из себя

Да кому ты нужен. Просто от ламерья ограждаю ТСа, который может оказаться достаточно наивным, чтобы тебе поверить. От мании величия смотри не лопни :)

По сабжу... сохранить никак. Но ты можешь тестировать кусками, указывая сектор начальный и конечный, подбирая размер куска под удобное тебе время работы. :)

который может оказаться достаточно наивным, чтобы тебе поверить

Не боись, я никому не верю ☺

И ты так говоришь, будто бы меня не знаешь!

Да не, выше ведь я уже написал решение. По ctrl+C он пишет номер сканируемого блока — с него в следующий раз и надо начинать. Все просто оказалось.

Ну тебя знаю. А рядом может бегать и кто-то более наивный. Зачем вредные советы терпеть? :)

Ну тут какая засада... проходов-то четыре. И они идут последовательно. Т.е. оборвав где-то посередине, ты оборвешь не просто посередине винта, но и посередине одного из проходов.

Да пофиг: если первый проход не выявил, вероятность бэда всего-то 1/256! Можно считать, что его там нет.

Проход состоит из двух подпроходов: сначала винт забивается данными по паттерну, потом идет проход чтения и проверки. Т.е. если ты оборвешь посередине подпрохода записи, то так и не пройдешь проверку на чтение.

Кстати, я так понял (судя по манам и выхлопу badblocks), что сначала весь диапазон сканируется путем записи байта 0xaa, а затем — остальных трех байт (0x55, 0xff и 0x00 поочередно).

Да ну нафиг!

Тогда проще dd'ой пройтись

Чорд!

Ты прав: я скачал исходник. А то, начал было радоваться: уже почти 2% без ошибок. А он, оказывается, только пишет... В общем, завтра наклепаю скриптик на баше и буду по кускам проверять. Или тупо dd'ой.

Решил сейчас скриптик накатать. Вот что получилось:

cat scansdg 

#!/bin/bash
FILE="badblks_data"
BLKSZ="10240"
[ ! -e $FILE ] && echo -e "START=\"0\"\nLAST=\"$BLKSZ\"" > $FILE

eval $(cat $FILE)
while true; do
	echo -e "START=\"$START\"\nLAST=\"$LAST\"" > $FILE
	badblocks /dev/sdg1 -b 4096 -svw -o sdg1-bads $LAST $START || exit 0
	START=$(($LAST + 1))
	LAST=$(($BLKSZ + $LAST))
done

Данные о последнем проходе пишутся в файл, поэтому при следующем запуске ничего пропущено не будет. По идее, как только раздел кончится, сканирование завершится.

Что-то скрипт запустил, а потом подумал: а какой длины числа в баше? Проверил: int64_t. Хватит.

Какой раздел, ты же весь винт сканить должен и там всё затирается :)

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

Разбей диск на части и так и сканируй.

Так это же полторашка для всякой пурги. Естественно, там только один раздел на весь диск.

В бэдблокс лучше отдавать не раздел, а все устройство

Вот, кстати, товарищ дело говорит. Побей его на тысячу условных кусков с перехлестом в несколько секторов и так и скань :)

В этом случае для mkfs придется преобразовывать номера блоков, т.к. оно считает от начала раздела.

Побей его на тысячу условных кусков

Я уже запустил сканирование по 10к блоков.

mkfs

а это-то тут при чем? Я когда про куски говорил, не имел в виду разделы)

Та не: я имею в виду последующее переформатирование с указанием бэдов.

Едрена вошь! За 40 минут только 10ГБ проверил. Это получается чуть больше 4МБ/с за полный цикл, т.е. 16МБ/с за один прогон.

Ну вот, недельку попроверяете, потом плюнете на это дело и сделаете проверку на чтение. Или вообще откажетесь от этой идеи.

Кстати, я буду сильно благодарен, если мне кто-то объяснит, какой смысл вообще проверять на запись? На чтение - понятно, чтобы потом информацию получить. А на запись зачем? Ну, предположим, диск не сможет на нужный сектор что-то записать. Так он заремапит его и запишет информацию в новое место. И никаких проблем.

потом плюнете на это дело

Не плюну: можно вообще этот скрипт в автозагрузку (rc.local) воткнуть. Пусть себе проверяет, пока весь диск не просканирует. У меня пока проблем с местом нет, могу полторашку подержать незаюзанной.

какой смысл вообще проверять на запись?

А что здесь непонятного? Вдруг у тебя в этом конкретном месте бэд, причем читается хорошо, а пишется никак. И вообще, проверка диска на чтение — это как проверка на свежесть помидоров по издаваемому ими шлепку о стену.

Так он заремапит его

Не у всех такие крутые диски. У меня старенький "green".

потом плюнете на это дело и сделаете проверку на чтение

Да ты упоротый что ли? Проверка на чтение ничего не проверяет. Это онанизм.

Ты его по усб подключил, что ли?

SATA же! Это очень даже нормальная скорость для старого HDD. Новые максимум 25 выдают…

SATA же! Это очень даже нормальная скорость для старого HDD. Новые максимум 25 выдают…

Не далее как месяц назад я на ST1000DM003 полные четыре прохода прогнал за тринадцать с половиной часов. Линейка у твоего должна быть около 100-120 метров (средняя по винту - не меньше 60), так что дело не в сате. Тут что-то не так.

Не у всех такие крутые диски. У меня старенький «green».

Ну и что? Ему три года, а не тридцать. Самое старое, что быстро нагуглилось: http://www.hardw.net/doc/30.htm#14 Год публикации - 2000.

Тестировать «на чтение» тоже будет только ламер, ибо тестировать оно ничего не тестирует :)

не, ну почему? У меня есть диск, который клинит на определённых дорожках. Хотя в целом ты прав конечно...

Эдди в этом сообщении уже ответил, почему :) Тестирование на чтение выявляет только нечитающиеся сектора.

Что-то скрипт запустил, а потом подумал: а какой длины числа в баше? Проверил: int64_t. Хватит.

да, 64 целое.

И да, совет: используй цепной код в качестве патерна. Его хранить не нужно.

какой смысл вообще проверять на запись? На чтение - понятно, чтобы потом информацию получить. А на запись зачем?

you make my day

это похоже тролль невиданной толщины с винфака. А вы — ведётесь.

Я всегда готов признать свою неправоту, если у оппонента найдутся убедительные аргументы. А если их нет, значит прав я.

Видит ЛММ, я этого не хотел. Но раз нормально не умеете разговаривать - отправляйтесь в игнор.

Вариант.

Terrorists win!

Очень рад, что доставил удовольствие. У вас тоже аргументов нет?

Аргументировать в ответ на полную чушь? Точно, тролль. :)

fasterase в mhdd прогонял? Вылечить конечно не вылечит, но полегчать может =)