» Компьютерная терминология

Сюда ли запостил?
Чего греха таить, много проблем и повторяющихся вопросов, как раз из-за неправильного толкования, а порой и простого непонимания смысла, вкладываемого в тот или иной термин. Потому призываю делиться тута своими знаниями. К примеру, сам не смог найти толкового объяснения фразе: "Прямой доступ к диску". Вот допустим, посекторное редактирование подразумевает прямой доступ к диску... или таких доступов может быть несколько и все они будут называться прямыми доступами, имеется ввиду доступ через порты, доступ через БИОС или еще через какую за$ницу. И потом, говоря о прямом доступе к диску, возможно правильно надо говорить так: прямой доступ к диску на уровне посекторного редактирования, прямой доступ к диску на уровне портов и т.д и т.п.?? Есть знающие люди, можете четко сформулировать данное понятие?

KLASS
IMO, "Прямой доступ к диску" означает доступ в обход стандартных механизмов, предоставляемых ОС, т.е. в обход доступа на уровне файлов (или файловой системы). А как такой доступ осуществляется -- это уже другая история. Это может быть, как ты правильно заметил, доступ через механизмы BIOS или еще более радикальный метод -- через программирование дисков на самом низком уровне (через порты), а также это может быть и доступ через механизмы "дискового драйвера", предоставляемые самой ОС. В любых современных многозадачных ОС это должен быть только 3й вариант, а иначе существует громадный риск повреждения данных.

ooptimum
Сенкс за участие.

Цитата:

А как такой доступ осуществляется -- это уже другая история

Совершенно согласен, другими словами способов "много"...

Цитата:

а также это может быть и доступ через механизмы "дискового драйвера", предоставляемые самой ОС

Вот тут не все ясно.... т.е. для приложений, это уже не будет являться ПРЯМЫМ доступом, раз он (доступ) осуществляется через драйверы самой системы, а именно для них (приложений) он осуществляется уже на уровне файловой системы. Т.е. это уже будет, прямой доступ непосредственно самой системы к диску, так?
К примеру, посекторное редактирование, предоставляемое редакторами дисков, можно назвать ПРЯМЫМ доступом к диску, в полном смысле этого слова?
Скажу простым языком, поправьте меня, если я не прав...
Прямой доступ к диску, это когда приложение\программа работает с диском в обход, предоставляемых ОС дисковых драйверов, а значит в обход файловой системы и, если какой то файл открыт системой или другим приложением, то приложению, которое работает в обход дисковых дров системы, на это наплевать, оно все одно может править или удалять этот файл. Если, используемый системой, файл заюзать низя, значит у данного приложения прямого доступа нет. Так?

KLASS

Цитата:

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

В принципе, можно с этим согласиться, но приведу несколько моментов.
Использует ли CHKDSK прямой доступ к диску? Т.е., если эта прога может работать без загрузки винды, и самое главное, имеет доступ к секторам диска, выходит она и имеет прямой доступ? С другой стороны, под виндой она же требует или отключить диск, или выйти из винды, если он системный. Вот как сказать, прямой доступ это или нет? Вопрос можно поставить так: Если уже ясно, что на уровне файловой системы можно заблокировать доступ к какому-либо файлу, то можно ли таким же образом заблокировать так называемый прямой доступ к диску?
А можно ли даже и на уровне файловой системы дать доступ к заблокированному файлу?
Спрошу так: если файловая система не дает доступ к файлу на чтение, а спомощью каких-либо программ или драйверов я получу этот доступ, это можно назвать прямым доступом? По-другому: если я, к примеру, сумел снять имидж системного диска находясь в самой винде, то это произошло с помощь прямого доступа? Обращаю внимание, что в ряде случаев для этого требуется Net Framework, это и есть что-то вроде драйвера, дающего доступ в обход файловой системы?
А быть может, предположу, что винда, точнее, её файловая система уже имеет прямой доступ, просто вопрос в том, как заставить её разрешить доступ к тому или иному заблокированному файлу? Вот тут и различаются 2 вида прямого доступа: Один вид - простой доступ к непосредственному редактированию секторов диска при помощи обыкновенных низкоуровневых редакторов дисков.
Второй - при помощи той же файловой системы получить доступ на чтение и редактирование всех заблокированных файлов, т.е., полный и прямой доступ к диску, который в любом случае просто более удобен и нагляден чем первый, поскольку блокировка таких файлов где-то изначально запрограммирована, то выходит, можно как-то это ограничение снять. Вот этот путь кажется мне более изящным и правильным по сути, хотя бы потому, что одно дело передвигаться по диску с помощью низкоуровневых редакторов дисков, ища адреса того или иного файла и т.д., а гораздо легче кроме наличия вышеуказанной возможности редактирования секторов, иметь простой и понятный доступ к таблице файлов и т.д. Должен сказать, что последнее утверждение основывается на предположении, что сама винда также имеет прямой доступ к диску посредством той же файловой системы.

Извиняюсь, я когда сказал

Цитата:

которое работает в обход дисковых дров системы

мягко говоря затупил
Не в обход дров, но в обход самой файловой системы... так будет вернее. Отсюда далее:

Цитата:

Использует ли CHKDSK прямой доступ к диску?

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

Цитата:

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

Только если выдернешь диск из ящика. Ведь прямой доступ он либо есть, либо его нет, так о какой же блокировке можно вести речь. Блокировка уже подразумевает отношение с файловой системой, а при прямом доступе файловая система уже не в доле.
[/q]
А можно ли даже и на уровне файловой системы дать доступ к заблокированному файлу?
[/q]
NT для того и придумали, чтобы небыло такого доступа на уровне файловой системы.

Цитата:

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

Какой же это прямой доступ, если ты используешь дрова, а значит и саму файловую систему...

Цитата:

По-другому: если я, к примеру, сумел снять имидж системного диска находясь в самой винде, то это произошло с помощь прямого доступа?

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

Цитата:

А быть может, предположу, что винда, точнее, её файловая система

Так думаю не стоит говорить. Мозгов и так бог не дал, а так я с тобой, еще больше запутаюсь.
Как это понять винда или ее файловая система? Винда это операционная система, а файловая система живет сама по себе, и думаю можно предположить, что это именно файловая система нужна винде для фунциклирования, а никак не наоборот. Потому говоря о файловой системе, вынь уже за бортом, со всеми драйверами и прочим.

Цитата:

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

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

Цитата:

Вот этот путь кажется мне более изящным и правильным по сути

Сусанин то не путь то тупик...

Цитата:

что сама винда также имеет прямой доступ к диску посредством той же файловой системы.

Врят ли это можно назвать прямым доступом, потому как это противоречит сути, прямой - значит в обход любой файловой системы. Представь: на диске нет "ничего", как Вынь может иметь доступ к "ничему", если ее даже саму поставить низя на "ничего", а прямой доступ к диску это и есть доступ к "ничему", т.е. к секторам, единице уже физической, а любая файловая система - это уже единица логическая, если конечно можно так выразиться. Не бейте пож. за не знание теории.

Добавлено
Опять я затупил выше, насчет

Цитата:

Какой же это прямой доступ, если ты используешь дрова, а значит и саму файловую систему

В данном случае наверное надо было сказать, что получить прямой доступ к диску можно при помощи некоторых программ, именно на низком уровне в обход самой файловой системы и в обход дров выни. Так что-ли? В общем темный лес.

KLASS

Цитата:

Использует ли CHKDSK прямой доступ к диску?


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

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

Цитата:

NT для того и придумали, чтобы небыло такого доступа на уровне файловой системы.

Согласен, но из этого вовсе не следует, что и сама винда не может иметь прямого доступа к диску.
Другое дело, что так называемый низкоуровневый доступ непосредственно к секторам и кластером, не через драйвер винды, а через собственный драйвер данной проги невозможно заблокировать средствами файловой системы, это так, но из этого отнюдь не следует, что сама винда вообще не имеет такого же прямого доступа к диску, просто те или иные файлы блокируются ею при попытке доступа к ним через её собственные драйверы, т.е. при попытке доступа через её файловую систему. Из можно сделать вывод, что любое обращение, изменение содержимого кластеров уже является прямым обращением к диску, поскольку изменяется и содержимое сектора. Следовательно:

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

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

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


Цитата:

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

Цитата:

Врят ли это можно назвать прямым доступом, потому как это противоречит сути, прямой - значит в обход любой файловой системы. Представь: на диске нет "ничего", как Вынь может иметь доступ к "ничему", если ее даже саму поставить низя на "ничего", а прямой доступ к диску это и есть доступ к "ничему", т.е. к секторам, единице уже физической, а любая файловая система - это уже единица логическая

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


Цитата:

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

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

devids

Цитата:

прога, которая работает с секторами диска, имеет к нему прямой доступ?

Ну да, только, что ты называешь работой с секторами?

Цитата:

если я создал или изменил файл средствами операционной системы, естественно при этом происходит обращение к драйверу файловой системе, который соответственно модифицирует содержимое кластеров. А сами кластеры они же в секторах находятся, следовательно, меняется и их содержимое. Что из этого следует?

Хех.. ничего. В моем, чайниковском, понимании сектор, является величиной (единицей, объектом) физической, когда же кластер логической, т.е. "вымышленной" и используемой уже самой файловой системой.
Из справки Windows:

Цитата:

Все файловые системы, применяемые в данной версии Windows для работы с дисками, используют размер кластеров, который представляет собой минимальный объем дискового пространства, который может быть выделен для хранения файла.

Т.е. это всего лишь некий объем с которым и работает файловая система.
Ведь понятие кластер "рождается" только при создании самой файловой системы, когда же сектор был есть и будет, не зависимо от наличия последней. По другому, если сектор можно "потрогать", то кластер ни-ни, потому, как его физически нетути. Т.е. посекторное редактирование, с которого я собссно и начал тему, как раз осуществляется посредствам прямого доступа к диску, в обход файловой системы, когда же речь заходит о кластерах, то это уже прерогатива самой файловой системы. Потому говорить, что Вынь используя свои дрова, имеет прямой доступ к диску, я бы не стал. Она имеет доступ к файловой системе, которая, в свою очередь, для работы с дисками, уже использует логическую величину, называемую рамером кластеров. Во как, сам не понял чего сказал Ой не бейте, мы в университетах не обучались (С)

Цитата:

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

Так ни это ли прямой доступ к диску и есть?

Цитата:

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

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

Цитата:

Драйвер винды непосредственно и прямо! работает с диском

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

Цитата:

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

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

Цитата:

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

Так ей это вроде как и без надобности

Цитата:

А что, для работы низкоуровневого редактора дисков файловая система не нужна?

А зачем она ему?

Цитата:

А он сам должен находиться на каких-то отформатированных виндой или иной операционной системой кластерах, тв можешь установить или запустить его самого на неотфоматированном разделе?

Ну да, только какое это имеет отношение к прямому доступу к диску. Т.е. есть физический диск, не размеченный и не формаченый, что говорит вынь когда обращается к такому диску: Ой! Не вижу, не слышу подмонтируйте мне его сначала, а потом разметьте, да еще и форматните, если не трудно... ну вот, а теперь я готовая сложить ваше файло. И что говорит тот же Diskeditor... ничего, переносит все молча, как настоящий полковник И пожалуйста редактируй сектора, т.е. вписывай в них чего угодно.

Цитата:

А винда с загрузочного диска может отформатировать чистый диск, установиться на него, ну и в каком случае уровень прямого доступа выше

Что еще за уровень прямого доступа, выше или ниже? Он либо есть либо его нет, третьего не дано. Тип (метод) доступа, это еще понятно, а уровень... Хотя, как ты сказал "ВЫШЕ"... то не значит ПРЯМЕЕ Вот попробуй, находясь в системе, убить ее, отформатив, например, загрузочный диск... не получится, то-то! А вот при помощи редактора дисков, находясь все в той же системе, можно убить и ее родимую и сам редактор. Почему? Потому, что используется прямое редактирование секторов.

Цитата:

Давай разберемся.

Давай... меня самого распирает, в хорошем смысле слова

Цитата:

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

Ну это понятно, только связь какая между прямым доступом и доступом юзеров к файлам реестра, не понял?

Цитата:

MFT мы не видим, но винда с ней работает

Не а, не так... мы ее, как раз можем увидеть, используя все тот же прямой доступ к диску, а вот вынь, напротив, не видит MFT, да и зачем она ей, потому, как это прерогатива уже файловой системы.

Цитата:

Соответствующий драйвер винды для работы с файловой системой уже имеет такой прямой доступ к диску, просто где-то на программном уровне в его коде вшиты ограничения для юзеров, вот и все.

Где ты такое прочитал? Информацию пож. в студию. Не верю (С).

БИОС на стадии загрузки использует прерывание int13 и в частности функцию 00h. Это и есть самый прямой доступ к диску. IMHO прямее не бывает.
Ему по барабану к какому дисковому приводу обращаться.
Вызов функции в программе осуществляется АН=00h. Дальнейшие операции с дисковыми подсистемами -функция 03h на запись сектора - KLASS правильно написАл, что сектор и кластер разные вещи, функция 05h отвечает за нанесение форматных меток которые и определяют размер кластера.
Функция 02h отвечает за чтение сектора.
Теперь по поводу прямого доступа- задача программы перехватить прерывание int13. БИОС по функции 00h позиционирует головки на цилиндр 0 и после этого система готова к вводу выводу. Послечего следует чтение по 02h.
Далее идет собственно процедура определения по сигнатуре 55АА.
А вот дальше если нужно определять куда обращаться, то нужно перехватывать int13, что как мне кажется делает SyMon. Причём процедура по моему идет не в обход int13, как об этом пишут а на перехват этого прерывания и не отдавая его операционной системе выполняются действия с диском. Если нужно какой либо проге получить прямой доступ к диску из под виндов - то и необходимо перехватывать прерывание, что система старается блокировать, к счастью ей это не всегда удаётся. Если я запутал то прошу не бить, а только грамотно отрихтовать

Ну вот и чела послушали, кто занятия не прогуливал, а то сам все понимаю, но сказать не могу. Сенкс, за разъяснение и потраченное время, на двоечников
Ichtio

Цитата:

Если нужно какой либо проге получить прямой доступ к диску из под виндов - то и необходимо перехватывать прерывание

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

KLASS
А что у тебя (прости господи), и после чего упало?

Ichtio
Да не... я просто к слову. Бесконечные стоны, про "упавшую Вынь", как в аду уже... вот я и провел параллель...

Щас перечитал все и мне стало весело
devids

Цитата:

Соответствующий драйвер винды для работы с файловой системой уже имеет такой прямой доступ к диску, просто где-то на программном уровне в его коде вшиты ограничения для юзеров, вот и все.

В предыдущем посту я спросил тебя где ты это прочитал и... опять я затупил... где же об этом можно прочитать-то
Начну издалека. Что такое ОС. Это некий большой ДРОВ (интерфейс, посредник) между двумя железяками. Одна из которых - это есть винч, и вторая, которая сидит перед монитором и думает, что она всегда логически верна. Теперь вопрос: Зачем, как ты сказал, на программном уровне, в коде ОС, зашивать какие-то ограничения для юзеров, чтобы у них не было прямого доступа к диску? Ведь это лишено всякого смысла, если принять во внимание тот факт, что сама ОС, а равно и файловая система (величины, как известно логические) были придуманы именно для того, чтобы железяке, сидящей перед монитором, было проще, доступней, легче, удобней "общаться" с железякой называемой винчестером, потому, как на низком уровне это не эффективно в обычных условиях. И вот, когда железяке, сидящей перед монитором, надоедает "общение" с другой железякой через посредников (файловую, а равно и операционную системы), но посмотреть, как там все устроено хочется, (Дарвин и Грибоедов видно были оба правы) и крутить винчестер отверткой низя, деньги уплочены, а просто крутить его в руках тоже не интересно, то она (железяка, сидящая перед монитором) использует "Прямой доступ к диску", в обход всех посредников, пользуя для этого некие инструменты, вроде того же редактора дисков. Улыбнись

KLASS

Цитата:

что ты называешь работой с секторами?

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

Цитата:

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

А вот давай уточним, что ты называешь файловой системой?


Цитата:

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

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


Цитата:

Цитата:Драйвер винды непосредственно и прямо! работает с диском

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

Цитата:Низкоуровневые редакторы дисков, по идее должны иметь собственный, независимый от винды метод доступа к диску.

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

А вот тут скажу так: ежели ты работая с низкоуровневым редактором диска имеешь прямой доступ к диску, так ведь и тут же можно сказать, что у тебя он не прямой, а к примеру, через монитор компьютера. Так вот такой же монитор для винды - файловая система, и не более.


Цитата:

есть физический диск, не размеченный и не формаченый, что говорит вынь когда обращается к такому диску: Ой! Не вижу, не слышу подмонтируйте мне его сначала, а потом разметьте, да еще и форматните, если не трудно... ну вот, а теперь я готовая сложить ваше файло. И что говорит тот же Diskeditor... ничего, переносит все молча, как настоящий полковник И пожалуйста редактируй сектора, т.е. вписывай в них чего угодно.

Вот ты можешь создавать с помощью Diskeditor файлы на неотформатированном диске? Нет! А винда его отформатирует и файлы создаст.


Цитата:

Вот попробуй, находясь в системе, убить ее, отформатив, например, загрузочный диск... не получится, то-то! А вот при помощи редактора дисков, находясь все в той же системе, можно убить и ее родимую и сам редактор. Почему? Потому, что используется прямое редактирование секторов.

А кто сказал, что невозможно в принципе? Это разработчики просто заблокировали такую возможность.


Цитата:

Цитата:Файлы реестра и некоторые другие заблокированы для доступа юзеров, но сама-то винда отлично работает с ними.

Ну это понятно, только связь какая между прямым доступом и доступом юзеров к файлам реестра, не понял?

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


Цитата:

Цитата:MFT мы не видим, но винда с ней работает

Не а, не так... мы ее, как раз можем увидеть, используя все тот же прямой доступ к диску, а вот вынь, напротив, не видит MFT, да и зачем она ей, потому, как это прерогатива уже файловой системы.

Файловая система - это всего лишь карта расположения файлов - MFT, она сама вообще ничего не делает. С картой расположения файлов - MFT работает соответствующий драйвер винды, который и закрывает непосредственный доступ к MFT юзерам. Для меня нет разницы между этим драйвером и самой виндой - это тоже самое. А ты почему-то пытаешься эту разницу найти, хотя её там нет. Это как ежели я буду рисовать карандашом бумажную карту расположения файлов - MFT, а ты говоришь, что дескать, прямого доступа у меня к ней нет - это карандаш и карта к этому отношение имеют, а тот кто этим карандашом по ней водит, вроде тут ни причем.


Цитата:

Цитата:Соответствующий драйвер винды для работы с файловой системой уже имеет такой прямой доступ к диску, просто где-то на программном уровне в его коде вшиты ограничения для юзеров, вот и все.

Где ты такое прочитал? Информацию пож. в студию. Не верю

Это я логически вывел, быть может, на самом деле и сложнее.

devids

Цитата:

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

Не согласен я... здесь не стоит смешивать такие понятия, как физическая и логическая организация файла, т.е. по-секторная и по-кластерная соответственно. Диск это есть внешняя память (единица физическая), ее-то ОС и «делит» на блоки фиксированного размера, который задается при форматировании и называется размером кластера, и имеют логический адрес, находящийся в MFT. Это, что есть логическая организация файла. Под физической организацией файла, понимается то, что диск (единица физическая) делится контроллером на сектора, которые в свою очередь, тоже имеют адреса, но уже физические, и в этих секторах хранятся данные. Данные и файлы, в данном контексте, не есть одно и тоже.

Цитата:

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

Ну, наконец-то, именно, обращение к диску (внешней памяти) непосредственно через сектора, т.е. через прямую адресацию и есть прямой, физический доступ к диску.

Цитата:

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

Нет такого понятия "Прямой доступ к диску самой ОС", хоть убей... это ты его придумал, а я с этим категорически не согласен... и выше я уже говорил, что не следует так говорить... Мало того, для меня понятие ОС есть нечто, что-то абстрактное, а ты ее всячески пытаешься представить в виде некой железяки...

Цитата:

что ты называешь файловой системой?

Приведу цитату:

Цитата:

Файловая система - это часть операционной системы, назначение которой состоит в том, чтобы организовать эффективную работу с данными, хранящимися во внешней памяти и обеспечить пользователю удобный интерфейс при работе с этими данными. Организовать хранение информации на магнитном диске непросто. Это требует хорошего знания устройства контроллера диска, особенностей работы с его регистрами и.т. д. (этим обычно занимается компонент системы ввода-вывода ОС, называемый драйвером диска). Для того чтобы избавить пользователя компьютера от сложностей взаимодействия с аппаратурой и была придумана ясная абстрактная модель файловой системы.

В принципе мне добавить тут и нечего...

Цитата:

каждый кластер имеет свой адрес в одном или нескольких секторах.

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

Цитата:

Так вот такой же монитор для винды - файловая система, и не более.

Сам придумал? Еще раз, если в обход файловой системы, то прямой, а все остальное лирика.

Цитата:

Вот ты можешь создавать с помощью Diskeditor файлы на неотформатированном диске? Нет! А винда его отформатирует и файлы создаст.

Ну правильно, что есть Файл:

Цитата:

логический!!! набор данных, воспринимаемый!!! как единое целое и занимающий один или более блоков на внешнем запоминающем устройстве типа диска или магнитной ленты;

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

Цитата:

А кто сказал, что невозможно в принципе? Это разработчики просто заблокировали такую возможность.

Допустим... будем считать, что пример не удачный. Но, если начать говорить о "прямом доступе самой ОС" теряется всякий смысл, вкладываемый в термин "Прямой доступ". В данном контексте ПРЯМОЙ-значит в обход. Исходя из этого я против используемого тобою понятия "Прямой доступ ОС" - такого понятия существовать, не может в принципе. Это не верно! Доступ могут иметь некие утилиты входящие в состав ОС, не более.

Цитата:

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

Я не говорил, что только! прямым доступом можно менять... этим я только хотел сказать, что нам положить на запреты выни и ее файловую систему. Тут думаю надо сделать оговорку: раз файлы – абстрактные объекты, обращаясь к диску напрямую, через редактор диска, мы имеем доступ не к файлам, но к данным, потому не корректно будет, в дальнейшем, ассоциировать прямое редактирование секторов с редактированием такой абстрактной единицы как файл.

Цитата:

Файловая система - это всего лишь карта расположения файлов - MFT, она сама вообще ничего не делает.

Цитата:

А ты почему-то пытаешься эту разницу найти, хотя её там нет

Дальше я тут и говорить ничего не стану, потому, как ты все валишь в кучу, для тебя что кластер, что сектор, что прямая, физическая адресация, что абстрактная, логическая... яйца одни, для меня же, нет. Одно левое семенное, одно правое, которое можно и отрезать, дети все одно будут
И вот потому, как наша дискуссия превращается уже в демагогию, позволю себе обозначить некоторые рамки, дабы не усугублять, а ты просто согласись с этими рамками или попробуй обозначить их сам:
И так, ты ввел в разговор, для меня, неприемлемое понятие, как «Прямой доступ к диску ОС». Для меня же понятие «Прямой доступ к диску» не есть понятие доступа абстрактной единицы ОС к диску. Итак:
Диск (внешняя память) есть физическое устройство, поделенное на физические сектора.
Физический сектор – минимальная единица внешней памяти (диска).
Каждый сектор имеет свой собственный физический адрес.
В секторах хранятся некие данные (не файлы).
Прямой доступ к диску, есть обращение к диску (данным), через физические адреса секторов, т.е. через единицы внешней памяти используя прямую (физическую) адресацию.
К примеру:
Разбиение винча на логические диски - это низкоуровневая операция, потому, к примеру, утилита DiskPart использует прямой доступ к диску, потому как работает через прямую адресацию. А вот, упомянутый выше chkdsk, работает именно через абстрактную, логическую адресацию. И вот эти обе утилитки являются частью одной единицы, под абстрактным понятием ОС. О каком же понятии «Прямой доступ к диску ОС» ты тут говоришь?

KLASS

Цитата:

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

Хочу задать очень важный вопрос, от которого и зависит смысл всей беседы: при форматировании раздела под ту или иную файловую систему, само его физическое пространство, отведенное под данный раздел, не считая конечно зоны, где находятся таблица размещения файлов и главная загрузочная запись, если она есть, т.е., все свободное пространство, годное для размещения данных, оно как-то изменяется физически, на него наносятся какие-либо метки, данные, изменяется как-то содержимое секторов и т.д.?
Только после того, как мы выясним этот вопрос, можно будет продолжить разговор.

Цитата:

оно как-то изменяется физически, на него наносятся какие-либо метки, данные, изменяется как-то содержимое секторов и т.д.?

Нет.

KLASS
Вот теперь выскажу свои соображения.
1 утверждение: Допустим, ты хочешь при помощи редактора дисков изменить какой-либо файл. Для этого ты находишь в таблице размещения файлов физический адрес сектора, в котором он находится и меняешь произвольным образом данные этого сектора.
Вопрос: Вот это действие можно назвать прямым доступом к диску?

2 утверждение: я изменяю какой-либо файл при помощи проги для его редактирования, к примеру, блокнот. Что происходит в этом случае? Блокнот дает команду винде, точнее её драйверу файловой системы. Драйвер находит в таблице размещения файлов физический адрес сектора, в котором находится этот файл, ищет путем некоего ( думаю, что никак не логического, так как оказывается, что никаких меток для организации логического доступа к секторам на диске не предусмотрено ) доступа к диску этот сектор и затем производит в нем изменение данных.
Вопрос: Как обозвать вот это действие?
Для упрощения предположу, что в данном случае размер сектора равен размеру кластера.
Можно про вышеуказанный драйвер сказать, что он явлется неотъемлемой частью винды и они оба не могут работать отдельно?



Цитата:

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

А как chkdsk может найти сектор только через логическую адресацию, не используя или не зная его физический адрес? А как с помощью только лишь логической адресации изменяет содержимое или переносит данные с одного сектора на другой? Да и после проверки раздела всегда выводится инфа и о количестве поврежденных секторов, а не кластеров. Другое дело, что тут наличие доступа и на логическом и на физическом уровне.


Цитата:

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


В принципе мне добавить тут и нечего...

А вот я хочу заметить, что имеется ввиду пользователь, а не винда!



Цитата:

каждый кластер имеет свой адрес в одном или нескольких секторах.

Опять не совсем понятно, почему ты смешиваешь понятия логический и физический адрес

Давай определимся с терминами: логический адрес файла - это физический адрес того или иного сектора в таблице размещения файлов.
Скажи свое определение, если я не прав.


Цитата:

если в обход файловой системы, то прямой, а все остальное лирика.

Опять определимся с терминами: в вышеприведенном мной примере блокнот не имеет прямого доступа к диску, так как обращается на логическом уровне к винде, не имея вообще никакого понятия о физической структуре диска. Драйвер, выполняющий запрос блокнота имеет полное понятие о физической и логической структуре диска и модифицирует в конечном счете данные в секторах, так или нет?
Для меня прямой доступ имеет средство, которое непосредственно, без посредников, изменяет данные в секторах. Ты видимо, имеешь ввиду, что если этот драйвер заглядывает в файловую систему, т.е. в таблицу размещения файлов, чтоб найти этот файл, а точнее, физический адрес сектора, в котором он находится, то это по-твоему, доступ через файловую систему? А тогда кто имеет прямой доступ к диску? Файловая система? Но ведь она сама точно ничего не изменяет, напртив, её изменяет тот самый драйвер, который и работает напрямую с секторами. А если при использовании редакторов диска, ты наугад, не зная, что находится в том или ином секторе, меняешь его содержимое, да это происходит в обход файловой системы, но на физическом уровне какая разница для диска между этими двумя подходами?
Скажу в заключение так: драйвер винды знает физическую адресацию и работает с ней, просто кроме того, он ещё должен знать и логическую стуктуру клстеров, т.е уметь работать с файловой системой.
Вот если б ты на мой вопрос:

Цитата:

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

ДА, тогда бы мне пришлось бы признать, что на отформатированном диске появляются какие-то метки на каждом секторе, по которым драйвер винды использует какую-то свою логическую адресацию и находит их, а следовательно ничего не смыслит в физической адресации.
Да, драйвер винды имеет ограничения: он не дает возможность редактировать таблицу размещения файлов и т.д., но спрошу: это ограничение на физическом или на логическом уровне. Если второе, тогда где-то разработчиками вшиты ограничения, и именно на логическом уровне, которые могли и не быть, но в обоих случаях характер взаимодействия с диском на физическом уровне никак не изменится. Ты можешь сказать, что дескать ежели нет файловой системы, то и данный драйвер ничего сделать не сможет, в отличие от редактора дисков, но не надо забывать, что это разные вещи, драйвер создавался как узкоспециализированное средство, и разработчики просто не видели смысла давать ему те же функции, что и редакторы дисков. Видимо из-за этих ограничений ты отказываешься признать возможность прямого доступа к диску для винды. Что ж, нужно уточнять термины...

devids
Почитай вот тута http://cs.mipt.ru/docs/courses/osstud/os.html потом еще раз перечитай свой пост, возможно ты внесешь "некоторые" изменения

Цитата:

Как обозвать вот это действие?

Если под действием подразумевать твой пост, то... беспредел

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

Низкоуровневый формат, формат логического тома и обнуление.
Под понятием "низкоуровневый формат", многие подразумевают обычное обнуление диска. На самом деле низкоуровневое форматирование поверхности диска делается на заводе, потому, что подразумевает запись на поверхности диска серворазметки. Делается при помощи серворайтера, что, сами понимаете, в домашних условиях просто не реально. Помимо нанесения серворазметки, низкоуровневый формат подразумевает создание рабочей зоны диска, основываясь на его таблице зонного распределения. Таблица зонного распределения это часть микрокода, содержащая информацию о размере и расположении зон на дисковой поверхности, находится в служебной зоне. Служебная зона это часть дискового пространства HDD, скрытая в недрах накопителя и недоступная средствами ОС и BIOS. Применяется для нужд самого накопителя: в ней хранятся рабочие программы контроллера, адаптивы, паспорт диска, таблицы дефектов, транслятор, значения атрибутов SMART и т.д. Все вместе они образуют специализированную операционную систему, управляющую винтом.
Транслятор это часть микрокода винта, отвечающая за преобразование логического адреса в физический. Запрос по интерфейсу идет в логической адресации (CHS или LBA), а головки едут туда, куда транслятор решит.
Логический формат (высокого уровня) - процесс создания разделов и файловой системы на магнитном носителе. Имеет средства для логического скрытия дефектов.
Заполнение нолями это очистка носителя от файловой системы с полным уничтожением всей информации на нем. Производится через интерфейс, путем записи нулей во все его секторы. Если запись осуществлять в обход функций ОС и BIOS (через порты), то происходит перерасчет контрольных сумм секторов и ликвидация логических BAD-ов. Обнуление производится внутренней программой DiskPart, либо сторонней, взять тот же Acronis DiskEditor или WinHex. Большинство USER'ов заблуждаются (я, и сам так предполагал ранее), думая, что при посекторном редактировании (считывании) диска, работая в той же DiskEditor, они работают с диском на физическом уровне. Это не так, это тоже логика, но только уровнем ниже файловой системы, так называемый прямой доступ к диску на логическом уровне, т.е. в обход файловой системы, не более. На низком уровне работает только сам винчестер (контроллер), т.е. на уровне своих технологических команд. Технологический режим это особое состояние накопителя, когда его ПЗУ и служебная зона открыты для доступа через интерфейс.

Аппаратные и логические бэды, ошибки файловой системы
BAD-блок это область дискового пространства, обычно размером с сектор (512 байт), утратившая способность хранения информации в результате повреждений.
Как известно сектор состоит из 2х частей, поле данных и поле с контрольной суммой этих данных. Когда контрольная сумма данных не совпадает, с записанной в соответствующем поле, диск выдает ошибку чтения (Unable to Correct by ECC). ECC (Error Correction Code) код коррекции ошибок, применяемый в HDD. Способ кодирования информации, когда к исходным данным добавляется их избыточность с контрольными суммами. Позволяет восстанавливать целостность данных, даже если они были прочитаны с ошибкой, а также сообщать об ошибках, если их было несколько.
Если это дефект поверхности, то это будет аппаратный бэд. Если же данные просто не совпадают с контрольной суммой (по разным причинам) и дефекта поверхности нет, то это уже логический бэд.
Помимо этого бывают еще логические ошибки файловой системы, возникают, как правило, при проблемах с питанием и чаще исправляются CHKDSK.

Переназначение секторов ("remapping")
Запись на диск происходит по принципу работы обычного магнитофона, идет запись и тут же, мы можем прослушивать эту запись. Современная головка винчестера - это комбинация МГ (индукционного типа) и головка считывания (MR - типа). Достаточно первым по ходу расположить зазор головки записи, а следом головки чтения и получаем результат: возможен контроль достоверности записанной информации на одном заходе. Если результат сравнения отрицательный, выходим на повторную процедуру записи при следующем обороте.
Есть у современных винтов такая вещь, как SMART Auto Off-Line Test. Его смысл, в определенный момент времени (обычно через некоторое время отсутствия команд от host-контроллера), производить обновление статистических данных (собственно SMART), а также производить тестирование секторов, ссылки на которые есть в логах ошибок винта. И если, во время этого теста, контроллер признает сектор дефектным - будет сделан "remap", при условии, что Auto Reallocate также включен (по умолчанию включен).
Понятно, что "ремапятся" только аппаратные бэды. Практически у всех современных винчестеров "remaping" прозрачен для пользователя. Диск производит "ремап" по одному ему известному алгоритму (определенная последовательность циклов чтения, записи, верификации сектора), этим занимается контроллер и сначала сбойный сектор заносится во временный G-List. G-list это часть таблицы дефектов HDD, пополняемая в процессе эксплуатации харда. Добавление дефектов осуществляет не пользователь, а сам накопитель в процессе ремапа. Число убранных дефектов можно легко узнать по значению SMART-атрибута Reallocated Sector Count. ОС с этим сектором (т.е. со всем кластером) работать не станет, потому что кластер будет помечен в MFT как "В". Теперь немного подробнее. Когда на диске появляются ошибки файловой системы и при чтении головками сектора, в котором есть данные с ошибками, контроллер сообщает системе, что этим данным доверять нельзя. ОС выкидывает сообщение о невозможности прочтения, а в MFT ($Volume) выставляется флаг запуска программы CHKDSK (при следующей перезагрузке компьютера), причем без ведома пользователя. При перезагрузке системы, происходит 10 секундный отсчет, и пользователь решает, разрешить запуск CHKDSK или нет. CHKDSK это программа, т.е. определенный набор команд, посылаемый, в конечном счете, диску. Если были ошибки файловой системы (принцип работы CHKDSK), они диском и исправляются, флаг запуска CHKDSK в MFT снимается. Если же ошибки исправить не удалось, CHKDSK мельком выкидывает сообщение о произошедших изменениях на диске (его можно потом просмотреть в "Event Viewer") и, загрузившись в систему, мы видим печально известные папки FOUND.00X или, вообще, не находим какие то файлы. Если имеет место быть бэд, сбойный сектор заносится во временный G-List и далее с ним имеет дело только сам диск и не факт, что он будет "заремаплен" сразу, контроллер будет еще работать с этим сектором, и возможно туда, впоследствии, будет произведена запись. Если мы имеем дело с логическим бэдом, можно загрузиться в DiskEditor, найти (логически) сбойный сектор и попытаться его обнулить. Надо полагать поэтому, при обнулении винчестера, исправляются некоторые ошибки, которые не смогла исправить CHKDSK. Если этот сектор перезаписать не удалось, возможно мы имеем дело уже с аппаратным бэдом и им будет заниматься сам контроллер.
Вообще, контроллер, очень трудно "убедить" в том, что сектор сбойный, это целая наука и все тонкости "ремапа" знает лишь специалист по ремонту конкретной модели дисков. Пользователю же можно воспользоваться известными программами (PC3000, MHDD), которые умеют выполнять ряд технологических команд, для того, чтобы "заставить" контроллер (не факт, что каждый) "сремапить" сектор "навсегда".

KLASS

Цитата:

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

Вот что я надыбал по этому поводу:
http://onehalf.pisem.net/stat/badblocks1.html

Цитата:

Почему же производители поступили так жестоко, лишив нас возможности делать правильное низкоуровневое форматирование, и скрывать дефекты самостоятельно? На этот вопрос до сих пор не существует единого мнения, но официальный ответ большинства фирм звучит примерно так: «это настолько сложная и опасная операция, что рядового пользователя до нее допускать нельзя, иначе многие винты будут попросту убиты. Поэтому низкоуровневое форматирование можно делать только на заводе, или в фирменном сервис-центре».

почему фирменные утилиты не делают никаких операций, связанных с прямым доступом к служебной области. Ведь скрытие дефектов форматированием - это практически полный ремонтный цикл, основанный на внешних параметрах и связанный с четким пониманием каждого шага. И достаточно сделать что-то неправильно, чтобы угробить накопитель. Приведем простой пример: пользователь решил сделать «настоящее» низкоуровневое форматирование путем запуска подпрограммы ПЗУ в технологическом режиме. Процесс обычно длится 10-60 минут, но тут случается перебой с питанием или банальное зависание - и винт остается без транслятора, т.к. просто не успевает его заново создать. Это означает, что к дальнейшей работе такой девайс будет непригоден - его просто не увидит ни ОС, ни BIOS. Страшно даже представить, сколько накопителей может быть убито таким образом, из простого любопытства или по ошибке. Особенно, если эти утилиты попадут в руки чайников, запускающих на своих компах все подряд и нажимающих RESET вместо «any key». Конечно, диск портится не безвозвратно, и повторным запуском форматирования можно вернуть его к жизни. Но мышление у большинства пользователей устроено так, что столкнувшись с проблемами (не определяющийся в BIOS труп вместо винта), многие впадают в панику, обвиняя во всем производителей. А им лишний геморрой, естественно не нужен - гораздо важнее заставить винт отработать гарантийный срок. Поэтому несколько лет назад в накопители стали закладывать возможность самостоятельно «ремонтировать» сбойные участки - делать ремап.

Цитата:

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

Вот что я надыбал по этому поводу:
http://onehalf.pisem.net/stat/badblocks1.html


Цитата:

Самые первые винты имели дефект-лист в виде бумажной наклейки, в которую на заводе вписывали адреса нестабильных участков. Эти устройства, представляющие собой слегка измененную копию обычного флоппи-дисковода, могли работать только под своими физическими параметрами: число дорожек, секторов и головок, указанное в их паспорте, точно совпадало с их реальным количеством. Приобретая такой девайс, пользователь читал наклейку и сам заносил адреса убитых участков в FAT. После этого операционная система переставала замечать эти дефекты, точно так же, как она не замечает бэд-блоки на дискетах, если они были убраны scandisk'ом. Вероятно, в те далекие времена и появился термин «бэд-блок»: блоком называли кластер - минимальную единицу логического дискового пространства. На физическом уровне кластер состоит из нескольких секторов, и при повреждении одного сектора ОС объявляет негодным весь кластер. Никаких других методов скрытия дефектов в то время не существовало. А когда появились способы скрывать отдельные секторы, люди не стали выдумывать новые понятия, и до сих пор успешно продолжают пользоваться словом «блок».
Прошло совсем немного времени, прежде чем изготовители додумались до очень интересной вещи: если пользователь все равно помечает bad-блоки, как ненужные, рассудили они, то почему бы не пометить их прямо на заводе? Но как это сделать, если на винте нет никакой файловой системы, и неизвестно, какая будет? Вот тогда и придумали хитрую штуку, называемую «транслятор»: на блины стали записывать специальную таблицу, в которой отмечалось, какие секторы следует спрятать от пользователя, а какие - оставить ему. Транслятор стал своеобразным промежуточным звеном, соединяющим физическую систему «диски-головки» с интерфейсом накопителя. Предполагалось, что при включении винт сначала прочитает свои внутренние таблицы, скрывая отмеченные в них адреса дефектов, а уже затем допустит к себе BIOS, ОС и прикладные программы. А чтобы пользователь случайно не затер транслятор во время работы, он был помещен в специальную область диска, недоступную обычным программам. Только контроллер винта мог получить доступ к ней.

Вот какую роль выполняет транслятор!
А причем здесь LBA?
Это делает кто-то другой?
Хотел бы уточнить: что понимается под преобразованием логического адреса в физический?
Допустим, я открываю какой-то файл, в конечном случае головки поедут туда, куда скажет контроллер и прочтут требуемые данные. Здесь все ясно. А что означает логическая адресация ОС контроллеру?
В каком виде запрос на открытие файла идет контроллеру?

Цитата:

Так же, как винт, ничего не знает о кластерах, (логическое понятие), ОС ничего не знает о цилиндрах (зонах), головках и секторах в физическом понимании

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

Цитата:

При этом также создается транслятор - часть микрокода диска отвечающая за преобразование логического адреса в физический.

Выходит, что транслятор получает запрос от ОС в виде типа: открой мне файл, находящийся в таких-то кластерах?
Транслятор понимает файловую систему?
А если не он, тогда что за вещь выполняет это преобразование --- адрес файла в виде кластеров -------- данные в таких-то секторах? Эта вещь, выходит, должна понимать и файловую систему и разбираться в секторах, т.е, грубо говоря, уметь находить по кластерам сектора, в которых находятся данные этого файла!
Я так понимаю, что винт как физичекское устройство, включая транслятор тоже, никак не может понимать файловую систему?
Следовательно запрос на открытие файла может быть дан ему в виде команды ---- пошли туда-то ( читай - на такой-то сектор, где находятся данные файла ) головку и прочти, что там находится? Так?
Следовательно, есть некий посредник ( вышеназванная неизвестная нам вещь, кстати эта вещь, если она находится вне винта, так скорее логическое понятие? ) который понимает, что такое и сектор, и кластер и преобразовывает запрос ОС на открытие файла в команду на чтение данных в таких-то секторах?
Другое дело, что этот некий посредник не имеет почему-то доступа ко всему диску, к примеру,

Цитата:

Как известно сектор состоит из 2х частей, поле данных и поле с контрольной суммой этих данных.

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


Цитата:

Есть у современных винтов такая вещь, как SMART Auto Off-Line Test. Его смысл в определенный момент времени (обычно через некоторое время отсутствия команд от host-контроллера) производить обновление статистических данных (собственно SMART), а также производить тестирование секторов, ссылки на которые есть в логах ошибок винта. И если, во время этого теста, микрокод винта признает сектор дефектным - будет сделан ремап, при условии, что Auto Reallocate также включен (по умолчанию включен). Тут надо отметить, чтобы заремапить сектор, для ряда накопителей, нужна не просто запись, а определенная последовательность циклов чтения, записи, верификации сектора.

Хотел бы знать, это у всех винтов такое есть или нет, а то в свое время был у меня бедастый винт, так я там такого не замечал...

Цитата:

Каким образом, при записи в плохой сектор или верификации этого сектора, винт понимает, что надо сделать ремап? Записывая\проверяя, контроллер делает несколько попыток такой записи, по одному ему известному алгоритму (этим занимается микрокод винта), потом заносит сектор в G-List, система, а равно и пользователь об этом ничего не ведают. При чтении же из сбойного сектора, где уже имеются пользовательские данные и их нужно выдать, контроллер сообщает файловой системе, что этим данным доверять нельзя

Как может что-то сообщить контролер файловой системе, если не понимает её?

Цитата:

Работает ремап следующим образом: если при попытке обращения к сектору происходит ошибка, «умный» контроллер понимает, что данный сектор неисправен, и «на лету» помечает его как BAD. Его адрес тут же заносится в таблицу дефектов (G-list). У многих винтов это происходит настолько быстро, что пользователь даже не замечает обнаружение дефекта и его скрытие. Во время работы винт постоянно сравнивает текущие адреса секторов с адресами из таблицы и не обращается к дефектным секторам. Вместо этого он переводит головки в резервную область и читает сектор оттуда. К сожалению, из-за времени, затрачиваемого на дальнее позиционирование, такие секторы будут выглядеть, как небольшие провалы на графике чтения. Тоже самое будет и при записи. Поэтому инженеры фирмы Quantum пошли еще дальше и почти устранили основной недостаток ремапа, воплотив свои идеи во многих моделях серии Fireball: у этих накопителей имеется по одному запасному сектору на каждой дорожке, ремап происходит в этот сектор, и задержки практически отсутствуют.

Если ошибка возникает во время обычной работы ОС, автоматический ремап происходит крайне редко. Это связано с тем, что, на большинстве хардов, reassign срабатывает только при записи. А многие ОС перед записью проверяет сектор на целостность, и обнаруживая ошибку, отказывается в него писать. Поэтому, в большинстве случаев для производства ремапа винт надо об этом «попросить» - произвести принудительную низкоуровневую перезапись сектора в обход стандартных функций ОС и BIOS. Это делается программой, способной обращаться к винту напрямую через порты IDE-контроллера. Если во время такой записи возникнет ошибка, контроллер автоматически заменит этот сектор из резерва, и BAD исчезнет.

На этом принципе основана работа большинства утилит так называемого «низкоуровневого форматирования» от производителей.

Не странно ли читать такое "А многие ОС перед записью проверяет сектор на целостность, и обнаруживая ошибку, отказывается в него писать."!!!
Сектор, а не кластер!


Цитата:

При чтении же из сбойного сектора, где уже имеются пользовательские данные и их нужно выдать, контроллер сообщает файловой системе, что этим данным доверять нельзя и ОС выкидывает сообщение пользователю, NTFS сразу помечает сбойный кластер в MFT ("B"), а также выставляется флаг запуска CHKDSK при следующей перезагрузке компьютера. Если это была ошибка файловой системы, она исправляется и флаг в MFT снимается, если же был сбойный сектор (в данном случае не важно, софтовый бэд или аппаратный), кластер остается помеченным в MFT (система к нему уже не будет обращаться, равно как и сам диск!).

Что именно понимается под чтением, попытка открыть файл его приложением?
Так на моем бедастом винчестере я неоднократно пытался открыть такие файлы, получал сообщение об ошибке чтения и более ничего!
А что значит, система не будет обращаться? Важно, смогу ли я продолжать обращатся к нему, и какая разница между первой попыткой обращения и последующими для юзера?

Цитата:

CHKDSK выкидывает сообщение и USER должен принять решение, как поступить с файлом, который будет перезаписан в другой кластер, т.е. с сохранением оставшейся целой части файла (печально известные папки FOUND.00X) или без такового.

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

Спасибо, за проявленный интерес к теме.
Исходя из твоих вопросов, я отредактировал часть "Ремап секторов", в остальном я не нашел разногласий в приведенной тобой ссылке и моим ходом мысли. В новый пост сувать не стал, больно они большие, потому отредатил предыдущий, см. выше.
На какие то вопросы отвечаю тут.

Цитата:

А причем здесь LBA?

Цитата:

А что означает логическая адресация ОС контроллеру?

Цитата:

видимо в виде адресов кластеров, в которых находится данный файл?

Нет, трансляция адреса в LBA т.е. не физические головки и сектора и не кластер, но когда каждый сектор имеет свой логический адрес, ассоциированный в MFT с кластерами. Скажем так, ты открываешь DiskEditor и видишь логические адреса секторов, то бишь абсолютный сектор 0, 1, 2 etc. но не физические, в буквальном смысле, а логические и вот транслятор их уже преобразует в физические.

Цитата:

Следовательно, есть некий посредник

Транслятор, т.е. микрокод.

Цитата:

Хотел бы знать, это у всех винтов такое есть или нет

Думаю уже лет семь точно, как у всех, если не больше.

Цитата:

Что именно понимается под чтением, попытка открыть файл его приложением?

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

Цитата:

А что значит, система не будет обращаться?

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

Цитата:

Важно, смогу ли я продолжать обращатся к нему

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

Цитата:

и какая разница между первой попыткой обращения и последующими для юзера?

Допустим, контрольная сумма не совпадает с данными (лог бэд), диск эту ошибку сразу исправить не может, вот ты ему и "помогаешь", обнулением, в данном случае обнуление и есть посланная тобой команда.

Цитата:

Хотел бы уточнить: что понимается под преобразованием логического адреса в физический?

Перевод из LBA в физические адреса секторов (зоны\цилиндры, головки\дорожки сектора) которые понимает только транслятор.

Цитата:

Никогда такого на моих аппаратных бедах не замечал

Возможно я не корректно выразился. При обращении к сбойному сектору, выставляется флаг запуска CHKDSK, без ведома пользователя, а вот когда ты перегружаешься идет отсчет (10сек) ты и принимаешь решение, нажал пробел и файл не будет ни скопирован ни уничтожен, не нажал - лотерея. Выше исправил.

Цитата:

Не странно ли читать такое "А многие ОС перед записью проверяет сектор на целостность, и обнаруживая ошибку, отказывается в него писать."!!!

Прочти в таком контексте. Перед записью, ось подает команду диску для прочтения головками какого то логического блока (LBA), чтение удалось, запись пошла, не более, т.е. она лишь подает команды. Диск, в отличии от оси, сам читает\пишет, но уже в физические сектора. Взять пример с обработкой секторов, которые занесены во временный лист, т.е. без ведома оси он делает неоднократные попытки исправить (читай перезаписать) сектор, чтобы изменилась его контрольная сумма и сектор стал пригодным для использования.

KLASS

Цитата:

трансляция адреса в LBA т.е. не физические головки и сектора и не кластер, но когда каждый сектор имеет свой логический адрес, ассоциированный в MFT с кластерами.

Я могу это понять так, что в MFT есть адреса секторов, а не только кластеров?
Другое дело, что ОС выдавая запрос на открытие файла, посылает его в виде команды прочесть данные с секторов под такими-то номерами, а в винте эта команда поступает на транслятор, который преобразует её в конкретный адрес сектора, дает команду головке и т.д.?
Скажем, если ОС дает команду на чтение кластера 1, то транслятор на самом деле обращается к кластеру 2, так как кластер 1 был ремапирован как негодный?


Цитата:

ты открываешь DiskEditor и видишь логические адреса секторов, то бишь абсолютный сектор 0, 1, 2 etc. но не физические, в буквальном смысле, а логические и вот транслятор их уже преобразует в физические.

Ещё вопрос: логический и физический адрес могут совпасть или нет?
Т.е., чтоб найти кластер номер такой-то, обязательно нужно знать адрес дорожки, цилиндр и т.д.?
По моему, нет.
Уточню, без транслятора ОС не может сама находить нужные секторы и оперировать с ними?
В подтверждение повторю приведенные цитаты:

Цитата:

Самые первые винты имели дефект-лист в виде бумажной наклейки, в которую на заводе вписывали адреса нестабильных участков. Эти устройства, представляющие собой слегка измененную копию обычного флоппи-дисковода, могли работать только под своими физическими параметрами: число дорожек, секторов и головок, указанное в их паспорте, точно совпадало с их реальным количеством. Приобретая такой девайс, пользователь читал наклейку и сам заносил адреса убитых участков в FAT. После этого операционная система переставала замечать эти дефекты, точно так же, как она не замечает бэд-блоки на дискетах, если они были убраны scandisk'ом. Вероятно, в те далекие времена и появился термин «бэд-блок»: блоком называли кластер - минимальную единицу логического дискового пространства. На физическом уровне кластер состоит из нескольких секторов, и при повреждении одного сектора ОС объявляет негодным весь кластер. Никаких других методов скрытия дефектов в то время не существовало. А когда появились способы скрывать отдельные секторы, люди не стали выдумывать новые понятия, и до сих пор успешно продолжают пользоваться словом «блок».
Прошло совсем немного времени, прежде чем изготовители додумались до очень интересной вещи: если пользователь все равно помечает bad-блоки, как ненужные, рассудили они, то почему бы не пометить их прямо на заводе? Но как это сделать, если на винте нет никакой файловой системы, и неизвестно, какая будет? Вот тогда и придумали хитрую штуку, называемую «транслятор»: на блины стали записывать специальную таблицу, в которой отмечалось, какие секторы следует спрятать от пользователя, а какие - оставить ему. Транслятор стал своеобразным промежуточным звеном, соединяющим физическую систему «диски-головки» с интерфейсом накопителя. Предполагалось, что при включении винт сначала прочитает свои внутренние таблицы, скрывая отмеченные в них адреса дефектов, а уже затем допустит к себе BIOS, ОС и прикладные программы. А чтобы пользователь случайно не затер транслятор во время работы, он был помещен в специальную область диска, недоступную обычным программам. Только контроллер винта мог получить доступ к ней.

Можно из этого сделать однозначный вывод, что ОС сама всегда оперировала секторами как физическими единицами?
Суть основного нашего с тобой разногласия:
Я полагал и полагаю, что преобразование логических адресов файлов - кластеров в конкретные адреса их размещения на диске - секторы выполняет только и только сама ОС! В таблице размещения файлов логические адреса файлов соотнесены с конкретным физическим адресом того или иного сектора! Транслятор служит лишь для замещения энного кол-ва плохих секторов хорошими и только при запросе ОС на такой сектор втихую, ничего не говоря ОС перенаправляет её запрос на сектор из резервной области, которым был замещен искомый нехороший сектор!
А в большинстве других случаев адрес сектора направленный ОС может совпасть с действительным физическим адресом сектора.
Преобразование логических адресов в физические осуществляется на уровне ОС, а никак не транслятора!
А по твоему выходит, что ОС дает логический адрес транслятору, а уж он преобразует его в физический!

Цитата:

ты открываешь DiskEditor и видишь логические адреса секторов, то бишь абсолютный сектор 0, 1, 2 etc. но не физические, в буквальном смысле, а логические и вот транслятор их уже преобразует в физические.

Цитата:Следовательно, есть некий посредник

Транслятор, т.е. микрокод.

Здесь видимо опять несостыковка в терминах, хотя мне казалось, что все ясно.
Есть ли вообще такое понятие логический адрес сектора?
Для меня два термина - логический адрес файла - кластер и данные, из которых состоит сам файл - физический адрес сектора!
А у тебя выходит два понятия логический и физический адрес сектора!
Для меня транслятор это нечто вроде этакого паразитного ролика между двумя валами в механике, который нужен только и только для переназначения плохих секторов и если ранее его не было, то значит ОС отлично работает с физическими адресами секторов, и посредником, о котором я говорил - это драйвер файловой системы, в принципе таже ОС!


Цитата:

Хотел бы знать, это у всех винтов такое есть или нет

Думаю уже лет семь точно, как у всех, если не больше.

На моем винте, который был гораздо новее, ничего такого ни разу не происходило.

Цитата:

Есть у современных винтов такая вещь, как SMART Auto Off-Line Test. Его смысл в определенный момент времени (обычно через некоторое время отсутствия команд от host-контроллера) производить обновление статистических данных (собственно SMART), а также производить тестирование секторов, ссылки на которые есть в логах ошибок винта. И если, во время этого теста, микрокод винта признает сектор дефектным - будет сделан ремап, при условии, что Auto Reallocate также включен (по умолчанию включен). Тут надо отметить, чтобы заремапить сектор, для ряда накопителей, нужна не просто запись, а определенная последовательность циклов чтения, записи, верификации сектора.

Можно ли это понимать так, что если, к примеру, у меня обнаружились плохие секторы, то через какое-то время они исчезнут, т.е. будет произведен ремап?
Скажем, я проверил диск и плохие секторы были занесены в MFT. Затем через месяц удалил раздел, заново создал раздел, отформатировал - что по твоему выходит, что этот сектор будет заремапен винтом? Проверка этого раздела уже найдет его?
У меня такого не наблюдалось...
Все равно хоть через месяц тоже число плохих секторов находилось.
Значит сам винт никакого ремапа не производит. А если не так, приведи свои факты...

Цитата:

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

Под логическим адресом понимается физический адрес сектора, который транслятор может подменить другим адресом, а может и не подменит?

Цитата:

А что значит, система не будет обращаться?

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

Вот впервые я пытаюсь открыть такой файл в лохом секторе. Получаю сообщение Ошибка чтения диска, ещё сколько-то раз пытаюсь это сделать - тоже самое.
Как это соотносится с твоим утверждением?
Бэд самый настоящий, аппаратный.


Цитата:

Возможно я не корректно выразился. При обращении к сбойному сектору, выставляется флаг запуска CHKDSK, без ведома пользователя, а вот когда ты перегружаешься идет отсчет (10сек) ты и принимаешь решение, нажал пробел и файл не будет ни скопирован ни уничтожен, не нажал - лотерея. Выше исправил.

Ни разу такого не было, никогда запросов на проверку не получал...

Цитата:

Перевод из LBA в физические адреса секторов (зоны\цилиндры, головки\дорожки сектора) которые понимает только транслятор.

А как же ранние модели винтов, в которых транслятора не было?
А ежели я достану такой винт, моя современная ОС не сможет с ним работать?
А могу я немного подправить твое высказывание и сказать, что Перевод из LBA в физические адреса секторов (зоны\цилиндры, головки\дорожки сектора) которые понимает не транслятор, а контроллер?
Транслятор не занимается переводом из LBA в физические адреса секторов, а лишь предназначен для подмены физического адреса того или иного сектора, т.е., при запросе сектора с адресом 1 он на самом деле обращается к сектору 2, точнее дает указание контролееру прочесть содержимое сектора 2, а уж последний и делает Перевод из LBA в физические адреса секторов (зоны\цилиндры, головки\дорожки сектора).
Роль транслятора сводится к тому, что он бодро рапортует ОС, что прочел данные сектора 1.
Разве эти действия транслятора можно назвать LBA?
Я во всяком случае в этом не так уверен, как ты...

Цитата:

Прочти в таком контексте. Перед записью, ось подает команду диску для прочтения головками какого то логического блока (LBA), чтение удалось, запись пошла, не более, т.е. она лишь подает команды. Диск, в отличии от оси, сам читает\пишет, но уже в физические сектора. Взять пример с обработкой секторов, которые занесены во временный лист, т.е. без ведома оси он делает неоднократные попытки исправить (читай перезаписать) сектор, чтобы изменилась его контрольная сумма и сектор стал пригодным для использования.

Вот тут ты уточни пожалуйста, что понимаешь под словом диск - транслятор или контроллер?

Цитата:

Я могу это понять так, что в MFT есть адреса секторов, а не только кластеров?

Да, только адреса секторов логические, ассоциированые с тем или иным кластером.

Цитата:

посылает его в виде команды прочесть данные с секторов под такими-то номерами

Под таким то логическим номером!

Цитата:

поступает на транслятор, который преобразует её в конкретный адрес сектора

В конкретный физический адрес сектора.

Цитата:

Скажем, если ОС дает команду на чтение кластера 1, то транслятор на самом деле обращается к кластеру 2, так как кластер 1 был ремапирован как негодный?

Ремапятся не кластеры, но сектора, если сектор заремаплен "насовсем", т.е. не во временный лист (это можно увидеть в SMART) и новый уже взят из запасника винта, то этот сектор уже невидим для пользователя. Если сектор попал пока только во временный лист, его логически можно увидеть через DiskEditor. Система же не видит целый кластер, в котором находится этот сектор (из временного листа), потому, как кластер помечен в MFT.

Цитата:

Ещё вопрос: логический и физический адрес могут совпасть или нет?

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

Цитата:

Т.е., чтоб найти кластер номер такой-то, обязательно нужно знать адрес дорожки, цилиндр и т.д.?
По моему, нет.

Правильно, нет.

Цитата:

Уточню, без транслятора ОС не может сама находить нужные секторы и оперировать с ними?

Физические адреса секторов - нет! Только логические.

Цитата:

Можно из этого сделать однозначный вывод, что ОС сама всегда оперировала секторами как физическими единицами?

Я со старыми дисками не работал. Но где то читал, что и тогда надо было различать физический (CHS) и логический адрес (CHS), вот тогда, возможно, они и совпадали. Это надо спрашивать у юзеров тех лет.

Цитата:

Я полагал и полагаю, что преобразование логических адресов файлов - кластеров

Кластер это логический объем, ассоциированный с некими логическими адресами, т.е. размер кластера, не более. Передаются в контроллер, логические адреса секторов.

Цитата:

В таблице размещения файлов логические адреса файлов соотнесены с конкретным физическим адресом того или иного сектора!

Никак нет, только с логическим адресом.

Цитата:

А по твоему выходит, что ОС дает логический адрес транслятору, а уж он преобразует его в физический!

Именно, только сначала контроллеру, а тот транслятору.

Цитата:

А у тебя выходит два понятия логический и физический адрес сектора!

Совершенно верно.

Цитата:

Для меня транслятор это нечто вроде этакого паразитного ролика между двумя валами в механике,

Транслятор это микрокод, программа.

Цитата:

На моем винте, который был гораздо новее, ничего такого ни разу не происходило

У мя, самого старому винту четыре года, там это все есть.

Цитата:

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

Это решает транслятор (Очепятка, не транслятор, но контроллер), но если он "сопротивляется" его можно заставить (не факт что каждый) программами указанными выше.

Цитата:

Скажем, я проверил диск и плохие секторы были занесены в MFT.

В MFT помечаются кластеры, а не заносятся.

Цитата:

Затем через месяц удалил раздел, заново создал раздел, отформатировал - что по твоему выходит, что этот сектор будет заремапен винтом?

Нет. А ты формат какой делал, полный? Если полный, то кластер в котором находится сбойный сектор будет помечен в MFT во время формата. Если быстрый то нет.

Цитата:

Значит сам винт никакого ремапа не производит.

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

Цитата:

Под логическим адресом понимается физический адрес сектора, который транслятор может подменить другим адресом, а может и не подменит?

Под логическим-логический, под физическим - физический Ось посылает логический, а транслятор переводит (не подменяет) в физический.

Цитата:

Вот впервые я пытаюсь открыть такой файл в лохом секторе. Получаю сообщение Ошибка чтения диска, ещё сколько-то раз пытаюсь это сделать - тоже самое.
Как это соотносится с твоим утверждением?
Бэд самый настоящий, аппаратный.

Не уверен, попробуй обнулить весь диск и эти бэды могут пропасть.
Микрокод у винтов так устроен, если он решил что есть дефект при чтении, то можно читать бесконечно и постоянно будет ошибка при чтении. Для того чтобы ошибок небыло надо сделать запись в этот сектор. Ось сначала подает команду на чтение, потому и записаться туда ничего не может. Если после записи (DiskEdit) все в порядке и читается нормально - микрокод считает, что сектор не дефектный и оставляет его в эксплуатации, если дефект остался и после записи - винт может сделать ремап.

Цитата:

Ни разу такого не было, никогда запросов на проверку не получал...

При загрузке системы? Да сколько угодно.

Цитата:

А как же ранние модели винтов, в которых транслятора не было?
А ежели я достану такой винт, моя современная ОС не сможет с ним работать?

Думаю через CHS трансляцию сможет.

Цитата:

которые понимает не транслятор, а контроллер?

Контроллер, по крайней мере современный, работает с логическими адресами.

Цитата:

Транслятор не занимается переводом из LBA в физические адреса секторов, а лишь предназначен для подмены физического адреса того или иного сектора

Занимается и тем и другим.

Цитата:

Разве эти действия транслятора можно назвать LBA?

LBA это тип трансляции адреса.

Цитата:

Вот тут ты уточни пожалуйста, что понимаешь под словом диск - транслятор или контроллер?

Диск, контроллер это два куска железа. Контроллер находится в диске. Транслятор тоже находится в диске и создается в служебной зоне винта, это микрокод и он уникален для конкретного экземпляра винта.

Цитата:

Я могу это понять так, что в MFT есть адреса секторов, а не только кластеров?

Да, только адреса секторов логические, ассоциированые с тем или иным кластером.

А можно ли сказать, что ОС имея пусть даже логические адреса секторов, понимает структуру диска, посылает запрос винту именно в форме типа " прочти данные из того-то сектора"?
Я под прямым доступом к винту всегда понимал именно это!
А уж логический это адрес или физический, не имеет принципиального значения.
Главное, что ОС оперирует именно понятием кластера!
Я и понимаю это как прямой доступ к диску, а вот если б запрос на открытие шел в виде "открой файл в таком-то кластере" вот это уже не есть прямой доступ!

Цитата:

посылает его в виде команды прочесть данные с секторов под такими-то номерами

Под таким то логическим номером!

Цитата:поступает на транслятор, который преобразует её в конкретный адрес сектора

В конкретный физический адрес сектора.

А характер логической и физической адресации отличается принципиально друг от друга?

Цитата:

Цитата:Уточню, без транслятора ОС не может сама находить нужные секторы и оперировать с ними?

Физические адреса секторов - нет! Только логические.

Цитата:Можно из этого сделать однозначный вывод, что ОС сама всегда оперировала секторами как физическими единицами?

Я со старыми дисками не работал. Но где то читал, что и тогда надо было различать физический (CHS) и логический адрес (CHS), вот тогда, возможно, они и совпадали.

Вот тут ты сам и подтвердил, что принципиальной разницы между логической и физической адресацией нет! Транслятор предназначен для подмены физического адреса ( который можно для упрощения назвать логическим ) который требует ОС и отвечает той же ОС, что да дескать я прочел данные из этого сектора, а на самом деле это может быть какой-то другой сектор. Принципиальная разница между логической и физической адресацией была бы если б скажем ОС оперировала бы другими единицами информации, скажем давала бы запрос в каких-либо других единицах инфы, скажем кластерах.
Для меня важно, что ОС понимает, что такое сектор и оперирует с ним как с единицей хранения данных! А если транслятор подменяет эти сектора и не дает доступа ко всему объему диска, так это неважно, потому, что в данном контексте и ОС обращается на его языке к диску и транслятор на том же языке отвечает. Вот это и есть прямой доступ, когда ОС представляет себе устройство диска, знает количество секторов и т.д.
Преобразование логической адресации в физическую меняет в принципе характер языка обращения к диску, что принципиально преобразовывается в этом случае?
ОС требует прочесть данные из энного сектора, а транслятор преобразовывает этот запрос в адрес предположим какой-то дорожки илии цилиндра? Нет.
Язык обращения ОС к транслятору и транслятора к диску абсолютно идентичен.
А вот язык обращения приложения к ОС на открытие файла один, и ОС преобразовывает его на команды поиска кластеров и затем данных в секторах. Вот здесь принципиальная разница. В нашем случае такой разницы не вижу!

Цитата:

А по твоему выходит, что ОС дает логический адрес транслятору, а уж он преобразует его в физический!

Именно, только сначала контроллеру, а тот транслятору.

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

Цитата:

На моем винте, который был гораздо новее, ничего такого ни разу не происходило

У мя, самого старому винту четыре года, там это все есть.

А подробно расписать можешь, как и что происходило?

Цитата:

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

Это решает транслятор, но если он "сопротивляется" его можно заставить (не факт что каждый) программами указанными выше.

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

Цитата:

Цитата:Вот впервые я пытаюсь открыть такой файл в лохом секторе. Получаю сообщение Ошибка чтения диска, ещё сколько-то раз пытаюсь это сделать - тоже самое.
Как это соотносится с твоим утверждением?
Бэд самый настоящий, аппаратный.

Не уверен, попробуй обнулить весь диск и эти бэды могут пропасть.
Микрокод у винтов так устроен, если он решил что есть дефект при чтении, то можно читать бесконечно и постоянно будет ошибка при чтении. Для того чтобы ошибок небыло надо сделать запись в этот сектор. Ось сначала подает команду на чтение, потому и записаться туда ничего не может. Если после записи (DiskEdit) все в порядке и читается нормально - микрокод считает, что сектор не дефектный и оставляет его в эксплуатации, если дефект остался и после записи - винт может сделать ремап.

Ты же сам выше говорил:

Цитата:

Возможно я не корректно выразился. При обращении к сбойному сектору, выставляется флаг запуска CHKDSK, без ведома пользователя, а вот когда ты перегружаешься идет отсчет (10сек) ты и принимаешь решение, нажал пробел и файл не будет ни скопирован ни уничтожен, не нажал - лотерея. Выше исправил.

Я обращался к сбойному сектору, но ничего такого не происходило...

Цитата:

Цитата:Транслятор не занимается переводом из LBA в физические адреса секторов, а лишь предназначен для подмены физического адреса того или иного сектора

Занимается и тем и другим.

Ещё раз цитирую из прежнего источника:

Цитата:

Прошло совсем немного времени, прежде чем изготовители додумались до очень интересной вещи: если пользователь все равно помечает bad-блоки, как ненужные, рассудили они, то почему бы не пометить их прямо на заводе? Но как это сделать, если на винте нет никакой файловой системы, и неизвестно, какая будет? Вот тогда и придумали хитрую штуку, называемую «транслятор»: на блины стали записывать специальную таблицу, в которой отмечалось, какие секторы следует спрятать от пользователя, а какие - оставить ему. Транслятор стал своеобразным промежуточным звеном, соединяющим физическую систему «диски-головки» с интерфейсом накопителя. Предполагалось, что при включении винт сначала прочитает свои внутренние таблицы, скрывая отмеченные в них адреса дефектов, а уже затем допустит к себе BIOS, ОС и прикладные программы. А чтобы пользователь случайно не затер транслятор во время работы, он был помещен в специальную область диска, недоступную обычным программам. Только контроллер винта мог получить доступ к ней. Это событие произвело настоящий переворот в винчестеростроении, и ознаменовало появление нового поколения накопителей - со служебной зоной. Для того, чтобы все винты одной модели, но с разным количеством дефектов, имели одинаковую емкость, на каждом из них стали оставлять запасные дорожки - резерв, специально предусмотренный для выравнивания емкости однотипных накопителей до стандартной заявленной величины
Для того, чтобы однозначно адресовать блок данных, необходимо указать все три числа - номер цилиндра, номер сектора на дорожке, номер головки. Такой способ адресации диска был широко распространен и получил впоследствии обозначение аббревиатурой CHS (cylinder, head, sector). Именно этот способ был первоначально реализован в BIOS, поэтому впоследствии возникли ограничения, связанные с ним. Дело в том, что BIOS определил разрядную сетку адресов на 63 сектора, 1024 цилиндра и 255 головок. Однако развитие жестких дисков в то время ограничилось использованием лишь 16 головок в связи со сложностью изготовления. Отсюда появилось первое ограничение на максимально допустимую для адресации емкость жесткого диска: 1024*16*63*512 = 504 Mb.

Со временем, производители стали делать HDD большего размера. Соответственно число цилиндров на них превысило 1024, максимально допустимое число цилиндров (с точки зрения старых BIOS). Однако, адресуемая часть диска продолжала равняться 504 Мбайтам, при условии, что обращение к диску велось средствами BIOS. Это ограничение со временем было снято введением так называемого механизма трансляции адресов.

Проблемы, возникшие с ограниченностью BIOS по части физической геометрии дисков, привели в конце концов к появлению нового способа адресации блоков на диске. Этот способ довольно прост. Блоки на диске описываются одним параметром - линейным адресом блока. Адресация диска линейно получила аббревиатуру LBA (logical block addressing). Линейный адрес блока однозначно связан с его CHS адресом:
lba = (cyl*HEADS + head)*SECTORS + (sector-1).
Это отодвинуло границу адресуемого BIOS'ом дискового пространства до 8 Gb.

Транслятор: часть микрокода винта, отвечающая за преобразование логического адреса в физический. Запрос по интерфейсу идет в логической адресации (CHS или LBA), а головки едут туда, куда транслятор решит.

Преобразования нет, просто та же подмена...

Цитата:

А можно ли сказать, что ОС имея пусть даже логические адреса секторов, понимает структуру диска, посылает запрос винту именно в форме типа " прочти данные из того-то сектора"?

Цитата: Вот это и есть прямой доступ, когда ОС представляет себе устройство диска, знает количество секторов и т.д.

А при чем тут прямой доступ, когда мы разговарили о процессе ремапа?

Цитата:

Принципиальная разница между логической и физической адресацией была бы если б скажем ОС оперировала бы другими единицами информации, скажем давала бы запрос в каких-либо других единицах инфы, скажем кластерах.

Хех.. ось и работает с кластерами (минимальная логическая единица хранения инфы)

Цитата:

просто транслятор в каких-то случаях может подменить реальный адрес одного сектора на другой...

Реальный адрес, это понятие зон, секторов и к логичесому адресу никак. Логический не есть реальный, он виртуален.

Цитата:

А подробно расписать можешь, как и что происходило?

У мя небыло ремапов (по крайней мере SMART молчит). Но то, что диск это умеет делать ты можешь сам узнать запустив утилиту читающую SMART. А процесс ремапа я подробно и описАл в подготовленном факе.

Цитата:

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

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

Цитата:

Я обращался к сбойному сектору, но ничего такого не происходило...

Просто ошибки бывают разного рода. Помнишь я те рассказывал, чтО надо сделать с файлом boot.ini? Там тоже происходит ошибка чтения. Вот и сделай, увидишь запуск CHKDSK при загрузке.

Цитата:

Преобразования нет, просто та же подмена...

Сам же привел цитату где сказано
[q]Транслятор: часть микрокода винта, отвечающая за преобразование логического адреса в физический.

Кажется, основная тема была и о разнице между логической и физической адресацией в том числе?

Цитата:

Хех.. ось и работает с кластерами (минимальная логическая единица хранения инфы)

А что такое сектор, не знает?

Цитата:

Реальный адрес, это понятие зон, секторов и к логичесому адресу никак. Логический не есть реальный, он виртуален.

Я могу это так понять, что в MFT адресам кластеров соответствуют некие виртуальные номера секторов или даже не секторов, а каких-то абстрактных ячеек информации.
Ты хочешь сказать, что тот номер сектора - его логический адрес как его понимает ОС и передает диску как запрос - он не имеет ничего общего с реальным адресом сектора на винте?
Еще раз приведу твою цитату:

Цитата:

Цитата:Ещё вопрос: логический и физический адрес могут совпасть или нет?

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

Цитата:Т.е., чтоб найти кластер номер такой-то, обязательно нужно знать адрес дорожки, цилиндр и т.д.?
По моему, нет.

Правильно, нет.

Цитата:Уточню, без транслятора ОС не может сама находить нужные секторы и оперировать с ними?

Физические адреса секторов - нет! Только логические.

Разберемся: чтобы найти на диске конкретный сектор, достаточно знать его номер - набор цифр?
это уже конечный пункт работы диска, задан номер сектора - его физический адрес и головки находят его. Здесь возражений нет?
Ты хочешь сказать, что логический адрес сектора - это тоже набор каких-то цифр, но не имеющий ничего общего с физическим адресом того же сектора?
Если так, то другой вопрос - откуда ОС берет этот логический адрес сектора?
Транслятор его сообщает, скажем при форматировании?
А если так, то можно сказать, что каждый уникальный логический адрес сектора жестко связан с таким же уникальным физическим адресом сектора на винте?
Скажем один сектор имеющий логический адрес 1111 всегда будет иметь физический адрес на диске 2222 и они никогда не будут меняться, если только... этот сектор не станет негодным и транслятор, произведя ремап, изменит его физический адрес, скажем 2222 на 3333, оставив неизменным логический 1111.
Значит, неясным для меня, во всяком случае, остается вопрос - можно ли найти очень большое кол-во секторов на винте, логические и физические адреса которых совпадают?
Если принять твою точку зрения, то получается, что транслятор где-то у себя формирует специальную таблицу, где физическим адресам всех секторов на диске ( абсолютно всех!!! ) сопоставлены логические, которыми оперирует ОС при обращении к диску, а уж транслятор преобразовывает их в физические, точнее говоря, получается, что при каждом запросе ОС транслятор заглядывает в эту таблицу, находит по ней физический адрес сектора и т.д. А если не так, то как ? Объясни это, пожалуйста по пальцам.
Не слишком ли большая таблица получается, да и нужна ли она?
А если, как предполагаю я, транслятор сообщает ОС реальные физические адреса секторов, и вот эта вышеназванная таблица есть только для небольшого числа секторв, которые ремапились, вот для них различаются физический и логический адреса!

Цитата:

А что такое сектор, не знает?

Физический, ессно, нет.

Цитата:

Ты хочешь сказать, что тот номер сектора - его логический адрес как его понимает ОС и передает диску как запрос - он не имеет ничего общего с реальным адресом сектора на винте?

Цитата:

Ты хочешь сказать, что логический адрес сектора - это тоже набор каких-то цифр, но не имеющий ничего общего с физическим адресом того же сектора?

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

Цитата:

Если принять твою точку зрения, то получается, что транслятор где-то у себя формирует специальную таблицу, где физическим адресам всех секторов на диске ( абсолютно всех!!! ) сопоставлены логические, которыми оперирует ОС при обращении к диску, а уж транслятор преобразовывает их в физические, точнее говоря, получается, что при каждом запросе ОС транслятор заглядывает в эту таблицу, находит по ней физический адрес сектора и т.д.

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

Цитата:

Не слишком ли большая таблица получается, да и нужна ли она?

Ну, под служебку и выделяет целая зона (группа трэков с одинаковым числом секторов на трэк), которая недоступна ни оси ни Биос, ни пользователю, расположенная на внешнем краю пластины.

Цитата:

А если, как предполагаю я, транслятор сообщает ОС реальные физические адреса секторов

Это вряд ли.

Цитата:

и вот эта вышеназванная таблица есть только для небольшого числа секторв, которые ремапились

Для этих секторов, там же в служебке, есть свои таблицы дефектов.

Цитата:

Ну, под служебку и выделяет целая зона (группа трэков с одинаковым числом секторов на трэк), которая недоступна ни оси ни Биос, ни пользователю, расположенная на внешнем краю пластины.

Не понял этого, т.е., ты согласен, что существует

Цитата:

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

Цитата:

Цитирую из вышеприведенного мной источника:
Прошло совсем немного времени, прежде чем изготовители додумались до очень интересной вещи: если пользователь все равно помечает bad-блоки, как ненужные, рассудили они, то почему бы не пометить их прямо на заводе? Но как это сделать, если на винте нет никакой файловой системы, и неизвестно, какая будет? Вот тогда и придумали хитрую штуку, называемую «транслятор»: на блины стали записывать специальную таблицу, в которой отмечалось, какие секторы следует спрятать от пользователя, а какие - оставить ему.

Из этого следует, что такой гигантской таблицы сопоставления абсолютно всех физических адресов логическим нет!
Ещё цитата из http://www.derstein.ru/good/good_4.html

Цитата:

в каждом HD существует таблица перераспределения запорченных секторов (участок дорожки). На ней и остановимся подробнее.
Хотите Вы того или нет, но ЛёБОЙ жесткий диск не лишен столь устрашающих каждого юзера bad-секторов - технология производства винчестеров пока не позволяет избавиться от них на все 100%. Здесь и приходит на выручку таблица перераспределения: при каждом включении винт считывает ее и просто "не замечает" битых секторов!
http://www.derstein.ru/good/good_33.html
Здесь нужно сказать, что микрокомпьютер винчестера, как и "большой" компьютер, имеет ПЗУ, в котором, аналогично BIOS, записана программа начального запуска, и ОЗУ, в которое после раскрутки механической системы загружаются остальные части управляющей программы (так называемый оверлей), что сильно напоминает процесс загрузки операционной системы компьютера. Кроме всего прочего, в ОЗУ загружается так называемая карта переназначения дефектов, в которой отмечены дефектные секторы, выявленные при заводской разметке дисков; эти секторы исключаются из работы и подменяются резервными, которые имеются на каждой дорожке и еще в отдельных зонах каждого диска. Таким образом, даже если диски и имеют дефекты (а при современной плотности записи они имеют их всегда), для пользователя создается впечатление "чистого" винчестера, свободного от сбойных секторов. Более того - на каждом винчестере имеется некоторый запас резервных секторов, которыми можно подменить и появившиеся впоследствии дефекты. Одни винчестеры делают это под управлением специальных программ, другие - автоматически в процессе работы. Однако повторюсь - полностью разметить себя на низком уровне современный винчестер не в состоянии.
http://www.derstein.ru/good/good_35.html
Хранение и извлечение данных с диска требует взаимодействия между операционной системой, контроллером жесткого диска и электронными и механическими компонентами самого накопителя. DOS помещает данные на хранение и обслуживает каталог секторов диска, закрепленных за файлами (FAT - File Allocation Table). Когда вы даете системе команду сохранить файл или считать его с диска, она передает ее в контроллер жесткого диска, который перемещает магнитные головки к таблице расположения файлов соответствующего логического диска. Затем DOS считывает эту таблицу, осуществляя в зависимости от команды поиск свободного сектора диска, в котором можно сохранить вновь созданный файл, или начало запрашиваемого для сохранения файла.

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

Информация FAT поступает из электронной схемы накопителя в контроллер жесткого диска и возвращается операционной системе, после чего DOS генерирует команду установки магнитных головок над соответствующей дорожкой диска для записи или считывания нужного сектора, при этом диск вращается со скоростью 3600 об/сек. Записав новый файл на свободные сектора диска, DOS возвращает магнитные головки в зону расположения FAT и вносит изменения в таблицу расположения файлов, последовательно перечисляя все сектора, на которых записан файл.
http://www.derstein.ru/good/good_39.html

Даже при уровне современных технологий, любой новый винчестер содержит неисправные блоки (bad block). Неисправный блок (или сектор) не позволяет считывать из него записанную ранее информацию. При первоначальной разметке, обнаруженные дефектные блоки заносятся в специальную таблицу переназначения. Далее контроллер винчестера, при работе, подменяет их на резервные, которые специально оставляются для этих целей.
http://www.derstein.ru/good/good_70.html

Что такое LBA?
Режим LBA использует линейную адресацию секторов, начиная с сектора 1, головки 0, цилиндра 0 как LBA 0 и заканчивая последним физическим сектором диска, который, например, на стандартном диске 540 Мб имеет номер LBA 1065456. Эта новинка появилась в ATA-2, но такая адресация всегда использовалась в стандарте SCSI.

LBA уменьшает загрузку CPU поскольку операционная система адресует сектора линейно (LBA), и эти адреса обычно пересчитываются в CHS (цилиндр-головка-сектор) для обращения к диску. При использовании же LBA, пересчета адресов не требуется.

Обрати вримание на последнюю фразу!

Цитата:

LBA (Logical Block Addressing) - адресация логических блоков. Стандарт ATA адресует сектор по классической схеме - номер цилиндра, головки и сектора. Однако, из-за исторически сложившихся причин, BIOS компьютера и операционная система DOS ограничивали количество секторов (63) и цилиндров (1024). В результате этого и появилось ограничение на объем жесткого диска в 540Мб. При режиме LBA, адрес передается в виде линейного абсолютного номера сектора. Винчестер в этом случае сам преобразует его в нужные ему номера цилиндров, головок и секторов. Это позволило обойти ограничения на объем жесткого диска, однако для DOS оно по прежнему составляет 8Гб. Работа устройства возможна только в случае поддержки этого режима драйвером (BIOS) и самим устройством.
www.derstein.ru/good/good_70.html#TrDetails
Как происходит трансляция?
Сегодня это может осуществляться, грубо говоря, тремя способами: стандартная адресация CHS, расширенная адресация Extended CHS и LBA. Как вы увидите, трансляция не реализует LBA автоматически.

1. Стандартная трансляция.
Обмен между диском, BIOS и операционной системой осуществляется по следующей схеме: Физическая геометрия T1
(внутреннее == использование) Логическая геометрия диска (CHS) === Логическая геометрия диска (CHS)


Здесь присутствует только один этап трансляции (T1), который является внутренним свойством винчестера. Реальная (физическая) геометрия устройства полностью невидима извне. Количества цилиндров, головок и секторов, напечатанные на этикетке для использования в программе установки параметров BIOS, никак не связаны с физическими параметрами винчестера. Логическая геометрия ограничена со стороны IDE (16 головок) и со стороны BIOS (1024 цилиндра), что в общей сложности ограничивает размер дисков (504MB).

CHS означает адресацию цилиндр-головка-сектор.

2. Расширенная адресация CHS
Физическая геометрия T1
(внутреннее == использование) Логическая геометрия диска (CHS) T2
===
Логическая геометрия диска (CHS)



Логическая геометрия используется для обмена между диском и BIOS, тогда как другая (трансляционная) геометрия служит для обмена между BIOS и операционной системой.

Трансляция осуществляется в два приема (T1 и T2). Этап T2 выполняется BIOS. Эта процедура позволяет преодолеть барьер 528MB, поскольку не накладывается одновременных ограничений BIOS и IDE: логическая геометрия не позволяет использовать более 16 головок, но число цилиндров не ограничено 1024. В трансляционной геометрии - наоборот.

В большинстве BIOS расширенная CHS-трансляция обозначается как опция 'LARGE'. Отметим, что геометрия, которую вы задаете в программе установки параметров BIOS (setup), является логической геометрией, а не трансляционной.

3. Логическая адресация блоков (Logical Block Addressing - LBA)
Здесь логическая геометрия целиком заменяется одним номером блока.

Диск BIOS ОС и приложения
Физическая геометрия T1
(внутреннее == использование) Линейный номер блока (LBA) T2
=== Трансляц. геометрия (CHS)


Физическая геометрия T1
(внутреннее == использование) Линейный номер блока (LBA) T2
=== Трансляц. геометрия (CHS)


Этот режим позволяет преодолеть барьер 528MB, также, как в extended CHS. Поскольку эта схема несколько проще в сравнении с CHS, она зачастую незначительно (читайте: незаметно) быстрее (в зависимости от качества драйвера LBA может оказаться даже несколько медленнее).

BIOS с трансляцией можно реализовать на системной плате или на плате контроллера. В общем случае используется принятая по умолчанию геометрия диска и, если число цилиндров превышает 1024, номер цилиндра делится на подходящее число (степень 2), а число головок умножается на то же число. Возьмем в качестве примера диск 540 Мб с 1057 цилиндрами и 16 головками. DOS может использовать только 1024 цилиндра, но умеет адресовать до 255 головок. BIOS с трансляцией будет передавать ОС через прерывание INT 13 измененную геометрию с 528 (1057/2 (округленно) цилиндрами и 32 головками (16*2). В этом случае при запросе к диску BIOS будет выполнять обратную трансляцию или вычислять LBA-номер (если режим LBA включен). Такой способ позволяет использовать диски размером до 8 Гб.

Детальное описание трансляции.
Если размер диска не превышает 528MB, должна использоваться логическая геометрия, как указано в словах 53-58 Identify Device (не более 1024 цилиндров, не более 16 головок и 63 секторов). Такие диски допускают прямую адресацию без использования трансляции.

Для дисков с размером более 528MB, CHS-адреса, которые BIOS получает от операционной системы, должны конвертироваться в адреса Extended CHS или LBA. Рассмотрим вариант использования Extended CHS. Во-первых, при установке параметров BIOS, должно быть определено значение N. Это число используется для преобразования геометрии диска в геометрию, поддерживаемую BIOS для прерывания INT 13H. Этот интерфейс требует, чтобы значение Cyl было не более 1024. Число цилиндров (слово 1 Identify Device) делится на N, тогда как число головок (слово 3 Identify Device) умножается на это число. N может иметь значения 2, 4, 8, ..., (степени 2).

Во-вторых, в большинстве BIOS с трансляцией используется приведенный ниже алгоритм используемый при работе с INT 13H:

eCyl = ( Cyl * N) + ( Head / dHead );
eHead = ( Head % dHead );
eSector = Sector;

Для примера предположим, что диск имеет 2000 цилиндров, 16 головок и 63 сектора (Identify Words 1, 3, 6), а значение N=2. BIOS сообщает DOS, что диск имеет 1000 цилиндров, 32 головки и 63 сектора при вызове INT 13H с AH=08H. Общее число секторов равно 2016000.


Таблица 8. Цилиндр Головка Сектор
Цилиндр Головка Сектор
LBA
0 0 1
0 0 1
0
... ... ...
... ... ...
...
500 0 1
1000 0 1
1008000
500 15 63
1000 15 63
1009007
500 16 1
1000 0 1
1009008
500 31 63
1000 15 63
1010015
501 0 1
1002 0 1
1010016
... ... ...
... ... ...
...
999 31 63
1999 15 63
2015999

Отметим одну особенность данного алгоритма: физический порядок секторов на диске не изменяется - за сектором n следует сектор n+1 при любой адресации CHS, Extended CHS и LBA. Разные способы адресации означают лишь различные алгоритмы трансляции, однако не все реализации BIOS поддерживают каждый из вариантов трансляции. Поэтому изменение алгоритма трансляции является потенциально опасным действием и может привести к потере данных на диске...

Какие выводы можно из всего этого сделать?
Жду твоих соображений...

Цитата:

Из этого следует, что такой гигантской таблицы сопоставления абсолютно всех физических адресов логическим нет!

Из этого, ничего не следует.
Цитата из статьи

Цитата:

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

И далее

Цитата:

в каждом HD существует таблица перераспределения запорченных секторов (участок дорожки). На ней и остановимся подробнее.

Речь идет о таблице дефектов!!, а ты провел параллель с логической геометрией диска. Причем тут геометрия диска с которой работает пользователь? Я же тебе в своем предыдущем посту уже говорил

Цитата:

Для этих секторов, там же в служебке, есть свои таблицы дефектов.

Далее, ты говоришь

Цитата:

Обрати вримание на последнюю фразу!

обращаю

Цитата:

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

и читаем предложение, которое было до этой самой фразы, тут же

Цитата:

LBA уменьшает загрузку CPU поскольку операционная система адресует сектора линейно (LBA), и эти адреса обычно пересчитываются в CHS (цилиндр-головка-сектор) для обращения к диску.

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

Цитата:

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

И все это из одного источника, причем на одной странице!

Цитата:

Какие выводы можно из всего этого сделать?

Искать надежные источники! Кстати, ты обратил внимание о каких дисках (десятилетней давности) там идет речь

Цитата:

Возьмем в качестве примера диск 540 Мб

С тех пор много воды утекло, а автор, хоть и составил страничку в 2003 (таких дисков то уже не было), использует старую инфу, затертую до дыр. Мдя...

Цитата:

Жду твоих соображений...

Скажем так. Они теже, что и были до твоего последнего поста. Добавить, вроде, как нечего. Так что жду твоих.

Цитата:

Цитата:Хотел бы уточнить: что понимается под преобразованием логического адреса в физический?

Перевод из LBA в физические адреса секторов (зоны\цилиндры, головки\дорожки сектора) которые понимает только транслятор.

Почему транслятор а не контроллер?


Цитата:

Цитата:Я могу это понять так, что в MFT есть адреса секторов, а не только кластеров?

Да, только адреса секторов логические, ассоциированые с тем или иным кластером.

Цитата:посылает его в виде команды прочесть данные с секторов под такими-то номерами

Под таким то логическим номером!

Этот логический номер есть абсолютный линейный адрес сектора, который поступает в контроллер?
Коротко резюмирую свое понимание вопроса.

Цитата:

Цитата:Т.е., чтоб найти кластер номер такой-то, обязательно нужно знать адрес дорожки, цилиндр и т.д.?
По моему, нет.
Правильно, нет.

Здесь я допустил описку, не кластер, а сектор!
И тогда это утверждение неверно!

Цитата:

Цитата:В таблице размещения файлов логические адреса файлов соотнесены с конкретным физическим адресом того или иного сектора!

Никак нет, только с логическим адресом.

Линейный адрес сектора это логический адрес?
Если да, как ты различаешь логический и физический адреса? Какая между ними разница?
Физический адрес всегда существует на диске в виде конкретного адреса сектора, так?
А линейный адрес откуда берется?
Мое понимание: Ос выдает контроллеру запрос в виде линейного адреса, который где-то жестко зашит в его прошивке, или же он как-то его рассчитывает. По ходу контроллер заглядывает в транслятор, убеждаясь, что данный сектор не переадресован как негодный и посылает головки на конкретную дорожку и т.д.
Я только сейчас разобрался, что по линейному адресу нельзя найти сектор, в этом была моя ошибка...


Цитата:

Ось посылает логический, а транслятор переводит (не подменяет) в физический.

По моему, это делает контроллер...

Цитата:

Контроллер, по крайней мере современный, работает с логическими адресами.

А разве ты не противоречишь сам себе?
Если транслятор переводит логический адрес в физический, то зачем контроллер должен работать с логическими адресами? Он же по-твоему получает конкретный физический адрес от транслятора?

Цитата:

Файловая система ассоциирует конкретный файл с цепочкой кластеров. Кластер пересчитывается в цепочку конкретных LBA. Транслятор преобразует LBA в реальную геометрию.

Какова роль в этой цепочке контроллера?