Это всего лишь вопрос к гипотетической проблеме.
Могут быть причины, по которым файл на жестком диске может быть поврежден.
Разве не здорово было бы иметь возможность, реконструировать их? Конечно, это заняло бы немного места, но у меня появилась идея, возможно, заархивировать это.
Обращение одного ха sh не даст полезного файла или части большого файла.
Просто оставайтесь со мной здесь.
Жесткий диск сохраняет файлы в заранее определенных размерах блоков. Все идет нормально. Теперь давайте сгенерируем ха sh. Его можно сохранить на жесткий диск следующим образом: фрагмент 64 КБ, фрагмент 64 КБ, ... блок 64 КБ с хешами. Конечно, необходим баланс, чтобы не тратить много данных на хеши. Теперь мы получили 2 информации. 1 - длина, 2 - га sh. Это само по себе не должно быть достаточно, если я правильно понимаю. Должен быть еще один га sh, исходя из другой формулы. Будет ли достаточно 2 хешей и известного размера куска для восстановления данных?
Каким-то образом, я думаю, это будет случайным, если это возможно. Некоторые чанки могут быть восстановлены, но иногда хеши 2 могут по-прежнему выдавать несколько данных. Если я не полностью ошибаюсь, каждый кусок заканчивается адресом следующего, верно? Давайте предположим, что с 20-летнего возраста плохая информация также может быть неверной Что, если адрес вызывается сначала как на ассемблере - адрес JMP. Этот код будет одинаковым все время. Предполагая, что адрес все время имеет одинаковую длину, и непосредственно перед тем, как есть команда JMP / jump, это повысило бы достоверность, верно?
И если это не достаточно, как насчет 3-го га sh для критических операций. (Предполагая, что 2 хэша, 1 известный байт и известная длина не приведут к восстановлению на 100% - я думаю, что это не так, но, скорее всего, закроется)
Теперь вы скажете ЭТО ИСПОЛЬЗУЕТСЯ ДЛЯ МНОГО ЦП. Ну, абсолютно верно. Но если он используется только на небольших секторах, я думаю, это не так много, если поврежден только небольшой сектор. Вот почему я просто использовал блоки по 64 КБ.
Но если хеши хранятся рядом с данными, огромный внезапный дефект жесткого диска все равно сделает восстановление абсолютно невозможным. Вот где появляется «слой 2»: каждый блок ha sh также заканчивается адресом другого блока с «Super-Ha sh». Это будет начинаться с источника (поскольку указатель блока уровня 1 га sh также может быть неисправен), а затем следуют хэши, построенные из хэшей слоя 1.
Конечно, если слой 1 ha sh to layer 2 ha sh указатель поврежден, система должна будет сканировать супер-ха sh. Возможно, было бы разумно не использовать адрес, указывающий на l2 га sh, а зарезервировать все возможные фрагменты super-ha sh в начале, а затем драйвер файловой системы автоматически вычислит правильное положение суперга sh.
До тех пор, пока это возможно и до тех пор, пока не повреждено слишком много джонков, восстановление "ВСЕХ данных" должно быть "относительно" эффективным. Но в действительности это сводится к одному вопросу:
Сколько хэшей вам понадобится, чтобы полностью восстановить информацию, которая была изначально декодирована в хэши? И какова поэтому минимальная га sh: скорость передачи данных, которую вы можете архивировать, не рискуя несогласованностью?
Почему я думаю, эта идея удивительна?
Хорошо, если вы используете жесткий диск как архив (резервная копия) для критических данных, это определенно может произойти. В некоторых случаях никогда не повредит дополнительной безопасности. Если это может быть эффективно запрограммировано, то оно также может быть незаметно медленнее.
- режим высокого уровня безопасности: сначала записывать хэши, чем данные
- режим высокой скорости: запись данных, ожидание низкого уровня использование диска / система простаивает или что-то еще, чтобы написать хэши. (на самом деле все еще довольно безопасно)
Также: в зависимости от системы: если система использует время простоя для дефрагментации жесткого диска, она может использовать эту возможность, чтобы проверить правильность данных после перераспределения. Я имею в виду, только наш мозг ограничивает возможности здесь.
Пока я вижу только одну проблему с этим: Есть много файловых систем. Маловероятно, что он будет реализован в каком-либо ядре linux, особенно в windows или ma c по понятным причинам.
Короче говоря:
Может ли это быть заархивировано без потерь 10-20% хранилища? И сколько данных вам придется потратить?
Дополнительно: в мире постоянно растущих масс данных все сложнее хранить все эти данные. Если процессоры станут более эффективными, я мог бы также представить этот метод, чтобы фактически сохранять файлы ТОЛЬКО в виде хэшей.
Это, так или иначе, определенно возможно, хранить огромный файл с относительно небольшой формулой - Проблема будет просто: вычисление этой формулы. Как и Пи - это число бесконечно. Как насчет формулы, которая дает бесконечные числа, но использует только первые несколько миллионов битов - что бы ни было указано первым. Это может сработать. А с квантовыми вычислениями это было бы возможно в режиме реального времени - если бы мы когда-нибудь получили настоящий квантовый компьютер на дешевом P C или сервере.
Есть какие-нибудь соображения по этому поводу? И, пожалуйста, не тратьте свое время, чтобы назвать меня сумасшедшим или глупым. Этот вопрос не для меня. Я действительно много думаю об этой "возможной" технологии.