Исходное сообщение
"Samsung предложил новый вариант драйвера exFAT для ядра Linu..." Отправлено пох., 23-Янв-20 15:08
предыдущими консистентными - метаданными. То есть соответствием inode indexes и тому что в них самих написано. fsck счастлив. А предыдущие консистентные _данные_ внутри этой inode - ниоткуда не возьмутся, они уже давно перезаписаны вообще другой информацией, а то что там должно быть - лежит где-то еще, но на это место не ссылаются метаданные, мы их "откатили" (поэтому ты не сможешь восстановить его из lost+found). То есть это именно битый файл. Если "забить на несколько последних испорченных файлов" - то да, но, к сожалению, продолжением является - "а теперь угадай, какие именно - испорчены". Это не какой-то баг ext2+, а врожденная фича всех не-cow fs (а cow приносит с собой свои, тоже не всегда прекрасные). То есть ситуация от ситуации вообще без журнала отличается только отсутствием необходимости ждать fsck - ценой потери производительности на "достаточно частое" переписывание из пустого в порожнее (оно синхронное, что радости не добавит) А вот откуда там у некоторых повышение производительности "в сто раз" - это действительно было бы интересно поизучать. Но у меня, увы, не наблюдается. > Заодно передаю привет https://www.opennet.ru/opennews/art.shtml?num=50148 эмм... поведение больших баз данных на ненадежном физическом носителе - по-моему предмет исключительно академического изучения, не? То есть, собственно, решение этой "проблемы" постгрезом - крэшнуться.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> предыдущими консистентными - метаданными. То есть соответствием inode indexes и тому что > в них самих написано. fsck счастлив. > А предыдущие консистентные _данные_ внутри этой inode - ниоткуда не возьмутся, они > уже давно перезаписаны вообще другой информацией, а то что там должно > быть - лежит где-то еще, но на это место не ссылаются > метаданные, мы их "откатили" (поэтому ты не сможешь восстановить его из > lost+found). То есть это именно битый файл. > Если "забить на несколько последних испорченных файлов" - то да, но, к > сожалению, продолжением является - "а теперь угадай, какие именно - испорчены". > Это не какой-то баг ext2+, а врожденная фича всех не-cow fs > (а cow приносит с собой свои, тоже не всегда прекрасные). > То есть ситуация от ситуации вообще без журнала отличается только отсутствием необходимости > ждать fsck - ценой потери производительности на "достаточно частое" переписывание из > пустого в порожнее (оно синхронное, что радости не добавит) > А вот откуда там у некоторых повышение производительности "в сто раз" - > это действительно было бы интересно поизучать. Но у меня, увы, не > наблюдается. >> Заодно передаю привет https://www.opennet.ru/opennews/art.shtml?num=50148 > эмм... поведение больших баз данных на ненадежном физическом носителе - по-моему предмет > исключительно академического изучения, не? > То есть, собственно, решение этой "проблемы" постгрезом - крэшнуться.
	Введите код, изображенный на картинке: