Bulat_Ziganshin
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата: Тут интересен момент насчет "пока живы заголовки" | есть несколько уровней "заголовков": 1. то, что я называю "геометрия ECC" - кол-во групп, число src/ecс секторов в них и их отображение на защищаемые файлы. Это можно записать всего в несколько десятков байт. Поэтому в моей утилите они хранятся при каждом секторе ECC. В par2/rsc32, к сожалению, эта инфа хранится только в суперзаголовке RR. Да, этого суперзаголовка делается куча копий (у rsc32 -hr3 по умолчанию), но если все эти копии накроются - можно ползти на кладбище. RAR, как я понимаю, хранит геометрию при каждом ECC-секторе, т.е. она фактически неубиваема (теряется вместе с самим сектором ECC). 2. CRC от исходных секторов - с ними возникает описанная мной в соседней теме коллизия. Опять же, afair, par2/rsc32 хранят её в хидер-блоках, которых делается всего несколько копий, а RAR - при каждом секторе ECC. Да, тут есть проблема в виде размера этой инфы, и RAR её обходит, ограничивая число секторов в одной группе сотнями, а не тысячами, как в PAR2, и даже миллионами, как в RSC32. Тут как раз и проявляется то, что RAR - это не суперутилита, выжимающая всё до последней крохи, но в пределах своих ограниченных намерений RAR отлично делает свою работу. 3. Оглавление самого архива, т.е. список файлов в нём. par2/rsc32 поддерживают защиту коллекций файлов, при этом они сохраняют список обработанных файлов, хотя бы чтобы знать какие сектора ECC каким файлам соответствуют. При потере этой инфы они просто не смогут ничего восстановить. Опять же, они делают всего несколько её копий в вышеупомянутых хидер блоках. Про RAR точно не скажу, но скорей всего он защищает эту инфу как часть архива, т.е. по дефолту у вас будет процентов 10 сего защиты, но зато 20 блоков восстановления, т.е. чтобы потерять хотя бы один блок - надо потерять 20 из 220 блоков этой конкретной группы Плюс прибавьте к этому то, что в новом формате RAR оглавление архива дублируется, что даёт дополнительный уровень защиты. В целом получается далеко не идеально, но вполне достаточно на практике и соответствует общему уровню защиты RAR 4. Ну и заодно уж скажу про защиту собственно данных. RAR делит исходные данные на сектора по 64 КБ, затем разбивает их на группы по 200 секторов с интерливингом - т.е. сначала идут первые сектора каждой группы, затем вторые сектора каждой группы и т.д. Ну и соответственно при 10% RR у вас получится всего 20 секторов ECC Т.е. схема RAR в целом правильная и даже хорошая, а вот уровень избыточности откровенно мал. Для сравнения в PAR2 до 32К+32K секторов на группу, а в RSC до нескольких миллионов (там ограничение 2 ГБ ОЗУ и размер сектора от 130 байт) Но это ограничение: во-первых позволяет сделать некоторые аспекты защиты принципиально более надёжными, чем это сделано у конкурентов (см. выше) и чем даже теоретически возможно при больших размерах групп (см. соседний тред) во-вторых позволяет обрабатывать данные без временных файлов (привет rsc32) - опять же, быстро обрабатывать группы в тысячи секторов без промежуточного файла того же размера, что RR, на HDD принципиально невозможно в третьих, значительно упрощает реализацию. Евгений сделал весь этот механизм за месяц-два. Учитывая, что он в две руки делает весь RAR от GUI до низкоуровневых алгоритмов, он просто не может себе позволить потратить полгода-год на одну только реализацию RR Добавлено: Цитата: Тест какой-то нереальной фигни в практическом смысле. | редкой, но вполне реальной. представьте что у вас рухнула файловая система, т.е. вы получили просто сырой образ диска (или флешки). это означает, что там есть в принципе сектора исходных данных, но идти они могут в любом порядке, хотя как правило будут длинные последовательные куски, но уж между собой жти куски могут быть перемешаны как угодно теперь смотрите, как с этим справляется идеальная утилита (т.е. моя собственная): во-первых, каждый сектор ECC сопровождается информацией о геометрии RR/архива и неким GUID, так что программа восстановления может собрать все выжившие ECC-сектора, сгруппировать их по GUID, и тем самым получить некий набор ECC-файлов во-вторых, каждый сектор ECC включает в себя информацию о CRC некоторых секторов исходного файла, плюс ECC поверх этой инфы. Итого, из выживших секторов ECC можно собрать инфу о CRC некоторых секторов исходного файла, плюс восстановить ещё больше черех механизм ECC на этом этапе у нас есть список CRC части секторов из исходных данных, мы можем пройти по сырому образу и извлечь из него эти сектора. После чего запускается обычных механизм восстановления, который получает на вход выжившие ECC-сектора и сектора данных, имея из метаданных ECC-секторов информацию о том, как эти сектора связаны в группы. Соответственно, восстановив группы в пределах сохранившихся данных, он может записать исходный файл точно в исходном виде Как я понимаю, RSC32 нацелен на такой же уровень восстановления, но у него неразвитая защита метаинформации. А RAR неплохо защищает метаинформацию, но в нём не реализован такой изощрённый поиск сохранившихся данных. Хотя я не знаю, может без переставновок он справится? |