OSDev

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

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

В CHS-адресации нет понятия "номер дорожки на цилиндре". Это, как ты верно заметил, номер головки. Цилиндр состоит из дорожек, имеющих один и тот же номер. Весь диапазон изменения номеров дорожек можно увидеть в пределах одной стороны/поверхности диска. Дорожки принято нумеровать именно так, хотя конечно тебе никто не запрещает нумеровать дорожки в пределах одного цилиндра, если в этом есть какая-то практическая необходимость.

Термины "цилиндр", "дорожка", "головка", "сектор" появились чуть-чуть раньше, чем BIOS -- лет эдак на 25-30. И словосочетание "номер дорожки (на цилиндре)" использовалось постоянно, и означало оно именно номер дорожки в пределах цилиндра, который, понятное дело, численно совпадал с номером головки. В общем, "Цилиндр состоит из дорожек, имеющих один и тот же номер" = бред, поскольку дорожки в пределах цилиндра нумеруются в возрастающей последовательности. Например, можно сказать: "третья дорожка пятого цилиндра сдохла и заменена на 20-ю дорожку 203-го цилиндра". Собственно, так и говорили и люди, и служебные программы, осуществлявшие контроль качества дисков и переназначение дефективных дорожек. Ну а сейчас так не говорят по той причине, что никто не видит этого процесса, да и с цилиндрами-дорожками-физическими блоками дел никто напрямую не имеет, кроме разработчиков дисков.

Всем доброго вечера!

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

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

_________________
Изучаю процессор...

Ищем по ключевому слову "журналирование".

На сколько я понимаю, ни одна FAT (ну точно не FAT12) не поддерживает восстановление данных после сбоев компьютера. Я прав?

_________________
Изучаю процессор...

Сама структура FAT такова, что ее можно восстановить после небольших повреждений, если факт наличия возможных повреждений быстро зафиксирован. Кстати для этого в FAT32 есть флаг закрытия. А в FAT1x тоже самое можно организовать в рамках конкретной ОС. Я когда демонтирую ФС на устройстве, в обязательном порядке выполняю закрытие. Если FAT1x не закрыта, то она не видна как FAT в других ОС.

Всем доброго вечера!

Вроде бы завершил придумывать свою файловую систему. Теперь буду писать несколько утилит, для того чтобы можно было создавать образы, форматировать дискеты и бродить по просторам файловой системы. Почитать про мою новую файловую систему Вы сможете по этой ссылке: http://dubrovkin.h18.ru/DFS-FD.htm.

Жду Ваших комментариев!

_________________
Изучаю процессор...

Посмотрел. Напиши какие по твоему она даёт преимущества по сравнению с ФАТ12. Аргументированно.

Полностью согласен, что моя файловая система очень уж громоздка. Я решил почитать спецификацию по FAT (http://www.gamedev.ru/files/?id=62689). Так же почитал статью: http://www.avprog.narod.ru/progs/fat.html#02h.

Решил написать для себя подобие FAT. По сути всё очень просто. Но есть несколько моментов, которые хочу чтобы Вы мне уточнили.

МОМЕНТ 1
В FAT может быть две области с описанием (характеристиками, цепочками) кластеров. То есть будет ли их две или одна, это по желанию. Корневая папка только одна. И как я понял, никакая папка не дублируется. И данные файлов тоже не дублируются, даже очень важные? То есть я имею в виду, что у нас может быть папка Soft в корневой папке. А в этой папке будет ещё папка Paint. Но может получиться так, что кластеры, где располагаются элементы этой папки, повреждены. И что, тогда мы просто-напросто потеряли не только ветвь развития, но и занятые кластеры? Как это реализуется, чтобы не потерять след. И собственно тоже самое касается файлов, не именно описания файла (то что находится в списке папки), а именно содержимое файла. Дублируется ли оно или как происходит. А то ведь так можно навсегда потерять данные в случае порчи сектора кластера. А если есть дубляж, то можно из дубля взять данные и поправить кластеры оригинала. Только тогда при каждой операции записи, нужно делать двойную работы (на оригинал и на копию). Оправдано ли это и как вообще делается в файловых системах?

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

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

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

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

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

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

Даже простое перемещение требует как минимум два раза записи (откуда и куда). А если все эти операции делать с учётом копий, то вообще чекануться можно.

Журналирование, журналирование... а как им реализовать всё это?

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

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

_________________
Изучаю процессор...