> снижает надёжность.
>Каким бы образом?Была статья-математическое иследование насчет дедубликации (на примере архивов).В среднем у юзера получалось экономия до 15-20% за счет одинаковых блоков,не считая сжатия, на обьем данных от 2 тб.И там доказывалось что при дедубликации больше чем на 3-х блоков надежность резко падает если в оригинальном блоке возникла ошибка.Как называемый "древовидный шторм".Правда это дело рассматривали для бэкапов и архивов , там же специалисты и предложили выход-одна из разновидностей корректирующего кода (не рида-соломанна из за избыточности) исправляющего до 5% ошибок при 1% увеличение места.(Теоретически можно использовать и проверочный crc32-но алгоритма пригодного для использования нету,вдобавок возможны коллизии.)
>без прогулки по всей площади спецутилитой
Давайте разбирем реальный пример -свежий диск не полностью заполнен.Пишем новые данные-все ок.Позже через час читаем сообщение Smart-не понравился один из свежезаписанных блоков как "слабый" и заменен.Ладно запускаем scrub и он падает через полчаса в корку-как я должен догадаться нормально у меня все с данными или нет-обратиться к скопированным данным и поглядеть нету ли ошибок CSUM ERROR? Я уже про fsck падающего от любого чиха не говорю.
>Получается что вам Linux использовать не надо, стремно же.
Хороший механизм экономящий память- но память быстрая и дефрагментировать ее практически не надо.Но как любой механизм тоже нуждаться в защите от шаловливых ручек-можно завалить мелкими отличающими страницами любой процесс,из за чего устанавливают ограничения.
