Вы просили доказательств, ну я в качестве примера и привёл данный сайт где фигурируют размер блока 256 и старые версии Виктории. В принципе, по большому счёту плевать на этот сей размер блока и закулисный алгоритм его расчёта. Чего там Казанский мутит по этому поводу меня особо не интересует. Для меня более важно иное - нестабильные плавающие результаты скана. Когда Виктория при скане находит медленный желтый/красный блок и бьёт тревогу пугая людей. Но при посекторном скане этого же блока, он вдруг оказывается довольно быстрым и вроде как и нет проблем. Фантастика! Вот что это за хрень такая? Зачем Казанский пугает людей? Можно же прописать в алгоритме теста автоматический посекторный перескан, если попался медленный блок, но нифига такого нет. Это невероятно как бесит.

Вы на дату опубликования статей этого сайта обращаете внимание? Еще не помешает в картинках к статьям обращать внимание на титульную строку на картинках с программой, в которых указывается и версия программы с которой сделан снимок. Например, к данной статье снимок приложен с версии Victoria 4.3 Freeware (beta version). В этой версии для любых дисков, включая SSD, размер блока устанавливается автоматически на 256, а интервалы отсечки задержек на 5,20,50,200,600,>,Err. В версии 4.47 с блоками и интервалами все тоже самое, однако, при этом время простого тестирования одного и того же диска, например, ST9500325AS подключенного к одному и тому же порту SATA II контроллера, на одном и том же ноутбуке различается значительно, ~2:20 против ~1:40 часа. Теперь возьмем версию 4.54, тот же диск и ноутбук. Блоки и интервалы там теже самые, не зависимо от типа и размера диска, а вот время полной проверки диска ST9500325AS опять возросло до  ~2:20 и даже чуть более. С версией 4.55b уже начинаются вопросы в том же самом окружении.

Диск 0 ST750LX003-1AC154, [block size]=2048, интервалы 25;100;250;1,0s;3,0s;>;Err, время ~2:00 часа
Диск 1 PLEXTOR PX-256M6M, [block size]=16384, интервалы 55;220;550;2,2s;6,6s;>;Err, время ~0:14 часа
Диск 2 ST9500325AS, [block size]=256, интервалы 5;20;50;200;600;>;Err, время ~2:25 часа
Диск 3 ST320LT020-8YG1, [block size]=2048, интервалы 25;100;250;1,0s;3,0s;>;Err, время ~1:00 час

С версии 4.54 на вкладке Standard появилась дополнительная строчка:
4.54 Диск 0 ST750LX003-1AC154 Sector: Logic 512 bytes, Phys 4096
4.54 Диск 1 PLEXTOR PX-256M6M Sector: Logic 512 bytes, Phys 512
4.54 Диск 2 ST9500325AS Sector: Logic 512 bytes, Phys 512
4.54 Диск 3 ST320LT020-8YG1 Sector: Logic 512 bytes, Phys 4096

Программа стала читать/распознавать/выводить параметры логических и физических секторов. И вот тут возникает вопрос про связь размера диска, размера физического сектора диска с размерами [block size] и временных интервалов. Получается, что для диска 2 в 500 ГБ, при размере логического и физического (Logic/Phys) секторов равного 512 байт, выставляется [block size]=256 и меньшие размеры отсечек временных интервалов по задержкам. Если смотреть выше и ниже, то для дисков в 750 ГБ и 320 ГБ, т.е. большего и меньшего размеров, но при не равенстве размеров логического и физического (Logic/Phys) секторов (512 не равно 4096), выставляются [block size]=2048 и одинаковые временные интервалы отсечек задержек при тестировании. Только вот для диска в 500 ГБ с [block size]=256 и интервалы меньше, но и время тестирования у него больше, чем у диска в 750 ГБ. Впрочем, последнее вполне объяснимо: диск ST750LX003-1AC154 SSHD SATAIII и подключен к порту SATAIII контроллера, а вот диск ST9500325AS и сам SATAII и подключен к порту SATAII контроллера. Вот у дисков ST9500325AS и ST320LT020-8YG1 параметры SATAII и порты подключения SATAII не отличаются, а [block size] у них разный, да и у большего по размеру диска он почему-то меньше. Где логика?

При этом, если почитать содержимое файлика Изменения.txt, вложенного в архив программы распростаняемого с официального сайта программы, в файле про изменения размеров блоков и всего связанного с этим нет ни строчки от автора. Вот к версии 4.55 там уже что-то имеется про [block size]=16386 для дисков SSD (и только для SSD). Если быть точнее, то там это значится как

Если копать далее и заглюянуть в файлик Изменения.txt к версии 4.66, то там обнаружим уточнение

Тут у автора рука дрогнула и он ошибся указав, что это новое относится к версии 4.65b-SSD от 28 июля 2018г, ибо ниже в том же файле есть примечания - Что нового в версии 4.65b-SSD от 23 июля 2018г. Однако к версии 4.72 прилагается файл whatsnew.rtf в котором можно прочитать

И тут у меня возникает резонный вопрос - Что за чушь и как быть с диском в 320 ГБ у которого автоматически выставляется [block size]=2048 уже с версии 4.54, да и диск 750 ГБ меньше (было - с 1Тб)? Что-то у автора тут явно не сходится. Упоминание про изменение блока с 400Мб есть и в дистрибутиве версии 4.69b, только файл там именуется Readme.rtf

Еще раз выскажу свое мнение про - А тут ничего проверять - по-моему не помешает и проверять, тем более при наличии возможностей, а истории про время уже из другой области. Тем более, что размер блока изменился и не только для SSD. Вы где-то уже ссылались на официальный FAQ, вот там в ответе на Вопрос #8 есть кое-какие разъяснения причин увеличения размера блока.

Соглашусь, тут я не совсем точно выразился. При только сканировании чтением, да пишет - Block start at ? (? GB) = ? ms. А вот при исправлении/переназначении плохих секторов там должен быть точный адрес сектора. Сектора в блоках с задержками еще не являются и не признаются программой плохими. В вашей фразе явно просматривается ссылка на ответ к Вопрос #13 из официального FAQ. Только там ниже еще есть Вопрос #14 с ответом про домашнее применение при лечении с функциями Erase или Remap и этот вопрос/ответ вы уже цитировали ниже. На здешнем сайте имеется статья https://remontcompa.ru/hard-disk/535-kak-proizvesti-test-zhestkogo-diska-v-prog
ramme-victoria-i-kak-ispravit-sboynye-sektora-bed-bloki-v-rabotayuschey-windows
.html с картинками на которых при [block size]=256 в лог выводятся строчки типа - LBA ? try REMAP ... - в которых номера LBA указывают явно на номера секторов, и явно не первых секторов в блоках по 256.

Так игрался уже. Сканить по одному сектору в 1000 раз медленней чем блоком секторов. Ну про опасно может я и перегнул палку, просто это Казанский в FAQ писал, вот я и зациклился на этом, хотя по идее я согласен, если уже сделана резервная копия данных, то опасности быть не должно. Вопрос-ответ из FAQ:

Я указал лишь, что сканить блоком секторов будет быстрее, чем сканить по одному сектору, а каков оптимальный размер блока я не в курсах, тут Виктория сама уж мутит оптимальный размер. Возможно какие-то размеры блоков в работе будут быстрее других, но с большой вероятностью они все будут быстрее размера блока равным 1 сектору, ибо там уж слишком медленная скорость. 

В лог пишется адрес первого сектора в блоке, а не адрес конкретного бэд-сектора. То есть, фактически пишет именно адрес начала блока секторов, с котором содержится n-ое количество бед-секторов.

Ну да, так собственно и есть. Казанский об этом прямо писал.

А тут ничего проверять. Размер блока в 256 секторов был указан в официальной документации к Виктории 3.5 в 2005 году, в те времена еще была официальная инструкция к проге. На каком-то этапе Казанский сменил логику, в какой именно версии я не в курсе. Но даже сейчас в 2021 году, во всех инструкциях на этом сайте remontcompa.ru фигурирует именно старый размер блока 256 секторов, хотя сейчас в Виктории 5.36 логика точно иная. На высокоскоростных SSD винтах блок в 256 секторов явно являлся узким горлышком, вот Казанский и решил его увеличить.

Про долго сканить по одному сектору вполне могу согласиться, а вот что подразумевается в логике под опасно, мне не совсем ясно. Прежде чем делать подобные выводы посоветовал бы в программе поиграться и параметрами и посмотреть, проанализировать результаты.

Если диск даже не поврежден и просто в идеальном состоянии, время сканирования все равно может играть против вас при изменениее [block size]. При этом время затрачиваемое на сканирование может увеличиваться даже при увеличении [block size] более 2048, что по вашему выводу - нужна высокая скорость скана - должно было время уменьшать. Проведите в программе эксперементы просто по чтению с игнорированием ошибок уменьшая значения [block size] от выбранного [auto] в 2048 по остальным ступенькам вплоть до 1 в сторону уменьшения и до 65535 в сторону увеличения. Полностью ожидать завершения теста не обязательно, вполне может оказаться достаточным от 1 до нескольких минут. Посмотрите как и на какие показатели и результаты эти изменения [block size] будут влиять. Только внимательно смотрите, там изменения можно будет наблюдать не только в поле вывода времени полного сканирования и счетчиках по интервалам. Кроме этого, не помешает запустить диспетчер задач и на страницах Процессы и Производительность понаблюдать как и на что влияет изменение размера [block size].

Если на диске имеются повреждения, при сканировании блоком секторов и обнаружении в блоке плохих секторов программа в цветных счетчиках циферки добавляет, в журнал записи красненьким пишет не по блоку секторов, она добавляет и пишет по конкретным номерам секторов. Если при запуске теста будет указан ремап, ремап также будет производиться не по счетчикам блоков секторов, а по конкретным секторам. Значит, при блочном сканировании, при обнаружении дефекта программа сама должна переключаться в посекторный режим на плохих секторах, а затем опять переключаться в блочный режим.

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

Определение LBA из официальной справки Victoria 5.36: LBA - Logical Block Address. Это номер сектора на накопителе. Один LBA обычно равен 512, 2048 или 4096 байтам. "Сектор" и "LBA" обычно являются синонимами.

Как говорится найдите 10 отличий ))). Определение с Википедии может быть и технически точное, но оно слишком мудрёное и тут явно лишнее, ибо вводит в заблуждение и автора данной статьи, и читателей. Сергей Казанский рассматривает один LBA как просто номер 1 сектора, а не номер блока секторов. Не знаю, все ли физические сектора входят в LBA, может служебные и резервные не включаются, ибо Винде о них знать необязательно, но это не особо важно. Следовательно ни о каких "блоков из секторов" речи идти не может. Первый сектор = LBA 0, второй = LBA 1, третий = LBA 2 и т.д. Но сканить и обрабатывать результат по одному сектору - очень муторно, долго и опасно(если винт поврежден, то время играет против нас, для достижения успеха - нужна высокая скорость скана), поэтому Казанский решил сканить и обрабатывать за один заход сразу несколько секторов, т.е. сканить сразу блок секторов. В старых версиях Виктории по дефолту для всех винтов действительно выбирался блок размером 256 секторов, но в новых механизм явно изменился: теперь на выбор размера блока влияет объем винта и скорей всего тип винта HDD/SDD и вид подключения. К примеру, для моего терабайтника, Виктория по дефолту выбирает автоматом размер блока 2048 секторов. Размер блока скана можно изменить вручную, вплоть до 1 сектора, но скорость скана существенно упадёт.

Заявление, что "При тестировании накопителя программа Victoria все адресное пространство жёсткого диска разбивает на условные участки (блоки одинаковой длины), размер одного блока равен 256-ти секторам." не совсем верно, ибо размер последнего блока при таком делении вряд ли будет равным 256/2048, всё таки у каждого винта разное число секторов и о механизме скана Виктории производители винтов ничего не знают. К примеру, на моём терабайтнике секторов LBA = 1953525168, но это число не делится без остатка на 256 и 2048, хотя если выбрать размер блока = 1 сектору, то всё получится и уложится в вашу фразу ))). Но всё же, правильней будет сказать, что Виктория просто сканит всё адресное пространство равными блоками.

Ну и во фразе "И вот нам с вами нужно определить, с какого именно номера блока секторов начинается диск (C:) и каким номером заканчивается ", для верности надо удалить слово "блока", т.е. сделать так "И вот нам с вами нужно определить, с какого именно номера сектора начинается диск (C:) и каким номером заканчивается" тогда всё станет гуд. Нам просто нужно найти номера нужных сектора, а не номера абстрактных блоков.

Спасибо, дополним статью.

Добрый день

Проверял диск Викторией и пока шла проверка, читал эту статью. После проверки решил по статье поиграться с программой и обнаружил вот что.

Если в Виктории после операций Advanced=>View part data выделить интересующий раздел и перейти на вкладку Test, то параметы Start LBA и End LBA автоматически выставляются для этого раздела, остается только нажать Start.

P.S Огромное спасибо админу и его коллегам за архиполезнейший сайт!

Спасибо andydron.

Можно еще начинающим посоветовать не вычислять так точно блоки, а в классическом случае, когда диск С находится в начале диска, и нужно проверить только его, то тест Виктории выставлять с начала (т.е. с нуля) а конечный блок чуть округленный вверх размер диска в гигабайтах умноженный на два (результат в миллионах). Например в данном случае пример выше это диск С размером 118 Гб. Выставить в Виктории проверку до 240`000`000 (118 ГБ округляем до 120 и умножаем на два - получаем 240 миллионов). Если перед диском С есть маленькие кусочки разделов, их размеры приплюсовать к диску С.
А вот если нужно проверить раздел посередине жесткого диска, только тогда уже вычислять точные метки начала и конца.
П.С. И вообще, если диск стал клацать головками - то тут уж обязательно надо проверять его весь (на вкладке Тест в Виктории еще желательно галочку "Remap" поставить, найденные ошибки Виктория постарается исправить не удаляя информацию). Но проверка жесткого это уже отдельная статья. :)

Спасибо! Буду знать, а то пока весь диск проверишь, запаришься ждать.