LINUX.ORG.RU

История изменений

Исправление intelfx, (текущая версия) :

Логи ядра?

Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check-ом).

Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.

Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.

Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.

Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть ровно два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.

В первом случае данные восстановить математически нельзя, во втором случае очень просто — достаточно вырезать или выключить код проверки этого тега.

А что лучше, использовать integrity или нет?

У тебя на уровне btrfs вычисляются контрольные суммы всех данных (но не криптографические). Если ты не защищаешься от атак с подменой шифротекста (chosen ciphertext attack), то dm-integrity тебе не нужно.

Неужели без него лучше восстановить данные?

Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.

Исправление intelfx, :

Логи ядра?

Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check-ом).

Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.

Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.

Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.

Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть ровно два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.

В первом случае данные восстановить математически нельзя, во втором случае очень просто — достаточно вырезать или выключить код проверки этого тега.

А что лучше, использовать integrity или нет?

У тебя на уровне btrfs вычисляются контрольные суммы всех данных (но не криптографические). Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.

Неужели без него лучше восстановить данные?

Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.

Исправление intelfx, :

Логи ядра?

Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check-ом).

Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.

Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.

Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.

Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.

В первом случае данные восстановить математически нельзя, во втором случае достаточно вырезать или выключить код проверки этого тега.

А что лучше, использовать integrity или нет?

У тебя на уровне btrfs вычисляются контрольные суммы всех данных (но не криптографические). Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.

Неужели без него лучше восстановить данные?

Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.

Исправление intelfx, :

Логи ядра?

Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check-ом).

Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.

Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.

Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.

Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.

В первом случае данные восстановить математически нельзя, во втором случае достаточно вырезать или выключить код проверки этого тега.

А что лучше, использовать integrity или нет?

У тебя на уровне btrfs вычисляются контрольные суммы всех данных. Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.

Неужели без него лучше восстановить данные?

Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.

Исходная версия intelfx, :

Логи ядра?

Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check-ом).

Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.

Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.

Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.

Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.

В первом случае данные восстановить математически нельзя, во втором случае достаточно вырезать или выключить код проверки этого тега.

А что лучше, использовать integrity или нет?

У тебя на уровне btrfs вычисляются контрольные суммы всех данных. Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.

Неужели без него лучше восстановить данные?

Не понял. Без журнала или без dm-integrity?

Без журнала всё плохо. А без dm-integrity каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.