Форматы кеша, поддерживаемые программой

[Tolik]

Вот и я сразу подумал про оперативку.

[T_Im]

Если CRC есть,можно сделать утилиту аналогичную опции RAR Протестировать архивы. Для быстрой проверки целостности.

Рекомендую для этой цели хорошую бесплатную утилиту ICE EСС
http://www.ice-graphics.com/ICEECC/IndexR.html
Позволяет создавать recovery файл с указанным % избыточной информации для восстановления. С помощью ее я обычно защищаю архивированные кэши на DVD, пару раз уже выручала.

[VMatveev]

Риальне страшилка: был кэш, стандартный тайловый кэш около двадцати миллионов файлов; примерно двести гигабайт. В один "прекрасный" день случился перебой в электропитании. При перезагрузке на винт с кэшем сработал стандартный chkdsk, после загрузки системы при попытке доступа к диску винда ругается, что диск повреждён или не отформтирован... Все попытки восстановления данных различными утилитами-рекаверилками успехом не увенчались. Не помог ни R-Studio, ни r.saver, ни другие утилиты. Стопроцентная уверенность, что именно проклятый chkdsk что-то "наисправлял" (наверно офигев от миллионов записей. ), а не перебой в питании и не возможные мелкие ошибки файловой системы.
Физический диск, специально выделенный под кэш SAS-а, оказался полностью исправным и после полного форматирования продолжает работать.
Получается что кэш из множества мелких файлов действительно очень уязвим. Это и логично: чем меньше записей в файловой системе - тем меньше она фрагментируется, и тем выше вероятность успешного восстановления. Думаю, даже при полном крахе ФС восстановить несколько крупных файлов намного легче и проще (при условии слабой их фрагментации! КО.), чем миллионы мелких. Да и крупные файлы намного удобнее бэкапить и переносить.

[vdemidov]

Проблема в том, что при крупных файлах возникает риск повреждения уже самих файлов. И если для файловой системы есть хоть какие-то инструменты восстановления, то для контейнеров таких инструментов практически нет.

[zed]

И если для файловой системы есть хоть какие-то инструменты восстановления,

Только вот не поедет ли у них крыша от миллионов тайлов - большой вопрос.

то для контейнеров таких инструментов практически нет

Ну, по крайней мере для Беркли, есть: db_recover. Так что не всё так плохо.

[vdemidov]

Ну, по крайней мере для Беркли есть: db_recover. Так что не всё так плохо.

Ну тут тоже ничего пока не известно. Может оно восстановит путем удаления всей инфы из файла? Да и битые тайлы оно не поправит. А учитывая что никаких контрольных сумм нету, то даже невозможно догадаться о повреждении содержимого тайла или информации о нем.

[vasketsov]

Я так понимаю, идеальным был бы вариант типа как в rar (некий % информации для восстановления)?

[DJ VK]

нашел неисправный гигабайт (memtest86+) и выкинул нафиг. трех хватит. Вот так и гробятся большие файлы.
за ICEECC спсибо, давно искал такую прогу, толку от RAR восстановления мало.
А вот расчет CRC и проверка в sdb все таки штука нужная. Хотя бы чтоб при попытке чтения такого тайла сообщала что он битый, и предлагала удалить или перекачать.

[Parasite]

Получается что кэш из множества мелких файлов действительно очень уязвим.

Не "кэш из множества файлов", а "файловая система NTFS, которая по дефолту хранит мелкие файлы в зоне $MFT (коя великолепно и распухает от этого) - и коя зона и чекается\изменяется при скандиске".
А скандиску крышу рвет от числа записей (бо он пытается обработать\проиндексировать все записи в уме и за раз, и при сотнях миллионов записей ему потребуются та еще куча ресурсов), и соответственно порет отсебятину.

Вывод: не юзать NTFS, не юзать штатный скандиск. В идеале - не юзать всю винду, там и других граблей хватает (тем более винду не серверных, а "домашних" версий - ХП и иже с ними, они изначально не предназначались для ТАКИХ объемов работ).

[Shurik]

Проблема с мелкими файлами в больших количествах возникнет в любой ФС. У меня вон reiserfs уже второй месяц делает rebuild tree, и завершено всего лишь на 60%, причём скорость скорее падает, чем держится на одном уровне. Смутно опасаюсь, что в итоге от файлухи мало что останется.