Просмотр полной версии : Вопрос. размер кластера. Фактическая структура ФС.
Cthulchu
05.02.2010, 03:15
[14:12] <Cthulchu> если при форматировании раздела выбрать размер кластера более маленьким, то больше ли битов будет затерто при полном форматировании?
[14:12] <Cthulchu> * затерто=переписано на единицы
[14:12] <Cthulchu> хочу быстро заэрейзить винт, чтобы не восстанавливался стандартными утилитами.
//собственно, устарело, но знать не помешает.
//фраза: "после форматирования не восстановишь" не канает.
//собственно, устарело, но знать не помешает.
//фраза: "после форматирования не восстановишь" не канает.
Совершенно столько же, при учете "полного форматирования", а не "очистка заголовка"
p.s. после перезаписи данных, поверх существующих, восстановить данные теоретически можно, по остаточной намагниченности между "полосами" на магнитном диске. Но это пока что фантастика.
Cthulchu
05.02.2010, 03:21
С точки зрения операционной системы, весь диск представляет из себя набор кластеров размером от 512 байт и выше. Драйверы файловой системы организуют кластеры в файлы и каталоги (реально являющиеся файлами, содержащими список файлов в этом каталоге). Эти же драйверы отслеживают, какие из кластеров в настоящее время используются, какие свободны, какие помечены как неисправные.
значит, у каждого кластера есть свои физические атрибуты, вписанные на винте, а значит, исходя так же из того, что размер кластера влияет на их количество на носителе, можно говорить о том, что изначально, затирается больше инфы. Ну, логично же, чем больше атрибутов на винте - тем больше места они занимают и тем больше бит переписывают собой.
Cthulchu
05.02.2010, 03:28
ну я себе изначально файловую систему представляю как сеточку, на границах сеточки (собственно, на всем пространстве, кроме ячеек) - системная информация, а размер ячейки и есть размером кластера, так что если форматировать с большим размером кластера, то шанс того, что файл попадет между ячейками - выше, нежели при "накладке" мелкой сеточки на крупную. вот я хотел утвердить или опровергнуть мое представление о ФС. Сейчас речь идет об NTFS.
ну я себе изначально файловую систему представляю как сеточку, на границах сеточки (собственно, на всем пространстве, кроме ячеек) - системная информация, а размер ячейки и есть размером кластера
Это утверждение можно считать верным.
что собой физически, на винте представляет граница между кластерами файловой системы? я думаю, что границой есть атрибуты кластера.
Зависит ли скорость форматирования от выбранного размера кластера, если отбросить время записи адресов кластеров в MFT?
вот такой вопрос частично отвечает на мой вопрос...
На первый вопрос я попытаюсь найти ответ, самому интересно.
На второй - ответ "Да".
Cthulchu
05.02.2010, 03:46
[01:34] <Cthulchu> супер вопрос, доброй ночи: Зависит ли скорость форматирования от выбранного размера кластера?
[01:34] * thorn (~thorn@92.243.166.21) has joined #windows
[01:34] <Cthulchu> если отбросить время записи адресов кластеров в MFT
[01:36] <{\> эм.. а причину узнать можно, которая этот вопрос породила?
[01:36] * {\ чувствует в чем-то подвох
[01:36] <Cthulchu> lf? ofc
[01:36] <Cthulchu> да, щас
[01:37] <Cthulchu> {\, http://pastebin.ru/310313
[01:38] <Cthulchu> у тебя ник является иньекцией в мой скрипт. красавчик.
[01:39] <{\> Cthulchu: красавчик - автор твоего скрипта. ник по RFC
[01:39] <Cthulchu> да не важно, есть что по ФС ответить?
[01:40] <{\> не думаю, что на глаз будет заметно
[01:40] <{\> хотя странная причина, да
[01:40] <{\> вообще при полном форматировании потерто будет все.
[01:41] <Cthulchu> но мне важно, чтобы терлось больше единицами, чем нолями.
[01:41] <{\> размера кластера влияет на размер MFT, если ты про NTFS
[01:41] <Cthulchu> MFT не играет роли, там у меня ничего ценного нету
[01:41] <Cthulchu> а вот остальное пространство как будет затираться - очень интересно
[01:42] <{\> возьми cleansweep и не мучайся. там подберешь подходящие опции
[01:43] <{\> честно, вопрос не имеет практической ценности :)
[01:43] <Cthulchu> да я уже отформатировал все тем же мхдд, лоу левел формат. потом еще килдиском с рендомным затиранием два круга
[01:43] <Cthulchu> просто дело в том, что я не представляю что пишется на винт во время форматирования и это не дает мне уснуть.
[01:43] <Cthulchu> кроме MFT, что пишется в зону файлов.
[01:44] <{\> возьми винт, форматни. сохрани дамп в файл. лучше никсовым dd. форматни еще раз и diff его, diff
[01:44] <{\> получишь вопрос на свой ответ ©
[01:45] <Cthulchu> эхх, думал, тут знают. пойду ка спать. спасибо за ответы, споки.
Ребят, если кто-то знает ответ, напишите, не мучайте наше время :(
Целиком вопрос не понятен. Есть некая область на диске, которую мы назваем сектором. Фактически, сектор - это не 512 байт, а несколько больше. Допустим, есть служебная информация, которая позволяет восстановить сектор при небольшом физическом сбое. Т.е. сектор читается с ошибками, но данные еще можно восстановить. Что-то подобное делалось в свое время для считывания дискет - сбой в 1 бит на сектор можно было компенсировать и прочитать данные. О заголовке сектора можно, в принципе, почитать - есть подробная информация, естественно на буржуйском.
Стандартная процедура форматирования (например заводская) просто записывает в каждый байт сектора F6 (если я не ошибаюсь). Такое форматирование не уничтожает данные - можно снять блины и прочитать остаточную намагниченность - данные будут извлечены полностью. Более правильно будет записать в каждый байт сектора сначала 01010101, а затем 10101010, повторив это минимум 3 раза. Это стандартный способ, применяющийся в правительственных учеждениях и в пакете Norton Utilities. Но лучше и быстрее просверлить блины в нескольких местах, а потом их переплавить - для надежности. ;)
Размер кластера не так уж принципиален - вы рискуете только последним кластером в цепочке данных, именуемых файл. Ибо, при записи, все выравнивается в бОльшую сторону до кластера.
На форматирование не влияет размер сектора - контроллер винта все равно читает дорожками, причем он их читает за раз тем больше, чем больше доступный кеш этого контроллера. В современных винтах есть еще и система "предугаывания" следующего сектора, что позволяет делать винты чуть скоростнее, чем без нее.
vBulletin® v3.8.14, Copyright ©2000-2026, vBulletin Solutions, Inc. Перевод: zCarot