Pull to refresh

Comments 12

А какие были предпосылки для создания OMFS3, если она, мягко говоря, повторяет FAT?
там задел для шифрования (пока реализовано только для Windows-монтера) + другая система адресации последующих кластеров (они хранятся непосредственно вконце текущего кластера), в FAT нужно при чтении иметь ввиду (и в памяти) всю FAT с указателями на кластеры. + некоторые мелочи (широкие атрибуты, 64 бит timestamp и др.)
там задел длдя шифрования (пока реализовано только для Windows-монтера)
Что мешает хранить в FAT шифрованные данные?
другая система адресации последующих кластеров (они хранятся непосредственно вконце текущего кластера)
Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.
в FAT нужно при чтении иметь ввиду (и в памяти) всю FAT с указателями на кластеры
Нет, с чего вы решили? Посмотрите спецификацию, саму FAT можно без каких-либо проблем читать on-demand. Просто держать ее в памяти удобнее, т.к. размер небольшой, а профиты в виде read ahead очевидны. В вашей же схеме read ahead сделать не получится.
некоторые мелочи (гирокие атрибуты, 64 бит timestamp и др.)
ExFAT? ;)

И да, если вы делаете упор на безопасность, подумайте о следующей ситуации — подлое ЦРУФБР уничтожило один кластер, который находится как раз посреди вашего файла. Что случится с FAT? В FAT файл будет с дыркой, но остальное прочитается. У вас, если же это был не самый последний кластер файла, хвост будет невозможно прочитать. Что будет, если повреждение придется на саму FAT? Ничего, т.к. в FAT есть возможность создавать теоретически неограниченное количество копий FAT (на практике, как правило, используются две). Т.е. при одинаковых условиях ваша ФС не сможет ни задетектить ошибку, ни исправить ее, ни предотвратить дальнейшую утерю данных.
Что мешает хранить в FAT шифрованные данные? — алгоритм, сжатие, вид шифрования, степень секретности — это всё нужно либо в файле хранить либо ОС должна думать. Тут это на уровне ФС атрибутов.

«Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.» — не совсем, это нужно для реального времени работы, нету лагов по чтению и поиску неизветно где находящегося в FAT кластера. Тут время предсказуемо, т.к. сразу получаем №след. кластера. Идея кстати не моя, где-то видел давно статью о подобном методе для ФС под ОСРВ.

ExFAT — лицензия + всё же не все атрибуты…
Что мешает хранить в FAT шифрованные данные? — алгоритм, сжатие, вид шифрования, степень секретности — это всё нужно либо в файле хранить либо ОС должна думать. Тут это на уровне ФС атрибутов.
Нужно поменять алгоритм шифрования — придется менять драйфер ФС?
«Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.» — не совсем, это нужно для реального времени работы, нету лагов по чтению и поиску неизветно где находящегося в FAT кластера.
Почему же «неизвестно где»? Смещение записи в FAT всегда известно с точностью до байта, а работа с жестким диском и реалтаймовость в принципе не совместимы, т.к. обычный жесткий диск не дает абсолютно никаких гарантий по поводу того, сколько будет длиться чтение отдельно взятого кластера.
Тут время предсказуемо, т.к. сразу получаем №след. кластера.
NCQ? Недостатки я описал выше — необратимая утеря данных и отсутствие возможности восстановления даже в теории.
ExFAT — лицензия + всё же не все атрибуты…
Произвольные расширенные аттрибуты, как и ADS, можно хранить и в обычном FAT, используя зарезервированные комбинации битовых аттрибутов — заодно это сохранит обратную совместимость с другими ОС.
1) внимательнее) — там алгоритм шифрования определяется атрибутом
2) Утеря данных. Если в OMFS3 потеряется несколько файлов (при порче диска), то FAT32 при порче обеих копий FAT потеряются ВСЕ файлы…
1) нет, вы не поняли. Вот у вас есть поддержка ГОСТ А и ГОСТ Б, реализованная в ядре ОС. Тут приходит к вам подлое ЦРУФСБ, протягивает мульярд долларов и говорит проникновенно "прифет, малшик, реализуй нам, пашалста, поддершку AES256CTR". Если бы у вас шифрование было отделено от ФС, то вы бы просто сделали еще одну, полностью независимую шифровалку, которая регистрирует себя, как прозрачный обработчик файлов определенного типа, связанного с AES256CTR. Т.е. для определенных конфигураций у вас идет только ГОСТ, а для других — и ГОСТ, и AES256CTR, а ФС одна и та же, и реализации ФС глубоко плевать на данные — ей главное их хранить, а что внутри — не ФСное это дело.

А вот если же у вас шифрование является частью ФС, а то и вообще ядра, то просто добавить шифрование уже не выйдет — придется выпускать новую версию драйвера или ядра, а это простой системы, перезагрузки, ошибки внедрения, ошибки обратной совместимости, и всякие прочие проблемы, о которых начинаешь думать, когда они уже произошли, все потерялось и поздно пить ბორჯომი. А оно вам надо? Вы ж вроде надежностью занимаетесь.

2) Нет, вы все еще не поняли. Повреждение FAT — это, конечно, неприятно, но давайте лучше посмотрим на примере.

Согласно документации MS, максимальное количество безопасно адресуемых кластеров в FAT32 не может превышать 4177918, что при максимально разрешенном официальном размере кластера в 32 KiB дает нам чуть меньше 128 GiB данных. На самом деле, спецификация FAT32 позволяет использовать разделы размером до 16ТиБ, но далеко не все реализации смогут себе это позволить — так что считаем, что у нас винт в 128 GiB. Примем размер сектора за 512, т.е. итого у нас 268435456 секторов (v). Для раздела такого размера FAT займет почти 16 MiB, или же 32768 секторов (f).

Теперь оценим вероятности. Вероятность того, что один сбойный сектор попадет на FAT — f/v ≈ 2-13.
Вероятность того, что два сбойных сектора окажутся в двух копиях FAT — f2/v2 ≈ 2-26.
Вероятность того, что оба сбойных сектора окажутся в двух копиях FAT с одинаковым смещением — f/v2 ≈ 2-41.
Вероятность того, что три сбойных сектора окажутся в трех копиях FAT с одинаковым смещением — f/v3 ≈ 2-69.

Последствия одновременного сбоя одного сектора во всех копиях FAT — временная недоступность 128 записей, при этом сами данные остаются на диске и их можно восстановить с большой долей достоверности путем поиска потерянных цепочек кластеров. 128 записей соответствуют 4 MiB данных. Последствия сбоя одного сектора в области данных — утеря 512 байт данных.

——
Теперь берем OMFS3. Раздел в 128 GiB содержит 2097152 кластеров по 64 KiB каждый. "Битовая карта" занимает 2 MiB, или 4096 секторов (b).

Вероятность того, что один сбойный сектор окажется в "битовой карте" — b/v ≈ 2-16. Последствия утери 512 байт в битовой карте — потеря 512 записей о состоянии кластеров без возможности восстановления, т.е. 32 MiB данных.
Вероятность того, что один сбойный сектор окажется в "FAT" — 1-b/v ≈ 99.9985%. Любое повреждение почти всегда будет попадать на область данных. Последствия одного сбойного сектора в области данных — необратимая утеря второй половины файла, т.к. в ФС нет механизмов, которые бы позволили обнаружить ошибку или исправить ее.

——————

Вы все еще уверены, что ваша ФС может называться "надежной", если она проигрывает даже такому говну, как FAT?
всё верно, но тем не менее. вторую копию FAT сейчас используют РЕАЛЬНО очень редко (особенно посторонние реализации). Соотв. остается именно одна копия.
И тут опа — произвольное повреждение диска (причина на важна), в т.ч. затерта часть FAT. — если затерта 20% FAT — то в реальности количество утерянных файлов будет больше (понятно почему). Восстановлению не подлежит в принципе (то что указано в FAT), т.к. неизвестно даже начального кластера. Грубая сила (т.е. поиск заголовков файлов ничего не дает, кроме первого кластера данных.)

Теперь OMFS. Аналогичная ситуация — затерта битовая карта. Не беда) — берем в каталогах начальные сектора — переходим на него (или грубой силой ищем заголовки файлов) — в конце кластера находится след. кластер. И по цепочке восстанавливаем файл.

Да, я уверен что такой принцип (пусть даже не моя OMFS, я о принципе) более надежен, по крайней мере для восстановления файлов — однозначно…
Да, я уверен что такой принцип более надежен
Ну что ж, в таком случае я могу лишь порадоваться за тех, кто не будет использовать вашу ОС. Успехов.
о, демки из 90-х) а вообще писать ОС на ассемблере — сизифов труд.
Когда я читаю название System 6 я вспоминаю сразу Macintosh System.

До сих пор помню, что когда я был мелкий и сидел за спектрумом дядьки хвастались, что кто то на свой мак систем 7 поставил и теперь доволен.
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention