Alexander
Проводить манипуляции, не сделав дамп, в любом случае нежелательно.
分解物質
Если дело только в чексуммах, то fsck, по идее, просто исправит их на актуальные и всё. В любом случае, лучше вариантом будет скопировать с помощью dd содержимое диска на другой и прогнать fsck там.
там не только чексуммы, оно ещё предлагает "Clear HTree index?" что звучит страшно.
а сделать dd некуда
分解物質
там 3TB почти
Alexander
там не только чексуммы, оно ещё предлагает "Clear HTree index?" что звучит страшно.
а сделать dd некуда
Это, вроде, лишь индекс каталога.
Но, в любом случае, смотри сам, что для тебя дешевле: рискнуть потерей данных или достать диск.
分解物質
Это, вроде, лишь индекс каталога.
Но, в любом случае, смотри сам, что для тебя дешевле: рискнуть потерей данных или достать диск.
> Это, вроде, лишь индекс каталога.
т.е. это только для ускорения поиска файлов? а они и без него доступны?
Alexander
> Это, вроде, лишь индекс каталога.
т.е. это только для ускорения поиска файлов? а они и без него доступны?
Я не настолько хорошо знаю устройство ФС, но, судя по тому, что пишут в сети, да.
Sergey
fsck предлагает фиксы но они похоже только зацементируют потерю данных.
соль в том что smart self test показывает что всё ок. а fsck пишет как будто совсем плохое что-то случилось:
e2fsck 1.45.5 (07-Jan-2020)
One or more block group descriptor checksums are invalid. Fix? no
Group descriptor 0 checksum is 0xc5a6, should be 0x95b3. IGNORED.
Group descriptor 1 checksum is 0xefb0, should be 0xbfa5. IGNORED.
Group descriptor 2 checksum is 0xf13b, should be 0xa12e. IGNORED.
Group descriptor 3 checksum is 0xf35a, should be 0xa34f. IGNORED.
Group descriptor 4 checksum is 0x4ab2, should be 0x1aa7. IGNORED.
....
Group descriptor 22333 checksum is 0xd7a8, should be 0x87bd. IGNORED.
Group descriptor 22334 checksum is 0xd99d, should be 0x8988. IGNORED.
Group descriptor 22335 checksum is 0xa7d0, should be 0xf7c5. IGNORED.
Group descriptor 22336 checksum is 0x38b0, should be 0x68a5. IGNORED.
в некоторых папках ls показывает имена файлов а открыть их нельзя: No such file or directory. те что открываются вроде как целые.
Я сейчас смотрю на disk layout и хекс дампы но как-то это затягивается
А данные сильно важные?
Если так заметно побились метаданные, то тут только два варианта:
1. Диск сильно не исправен , и ты рискуешь своими экспериментами его добить
2. Поврежден сата-кабель, или его сас аналог, плохой контакт у разъёмом, сильно окислились контактные площадки у платы под диском (характерно только для старых устройств)
Тут я не беру в расчёт намеренное выключение журналирования и прочие тюнинги
Sergey
Касательно смарта:
Его селф тестам далеко не всегда нужно верить. Оценку состояния диска нужно проводить через отслеживания динамики появления ошибок чтения/записи в смарте. "Битые" сектора и другие страшные страшности, о которых может сообщать смарт, могут быть вообще не бедами а чисто программными ошибками
Sergey
В общем, если даные сильно важные, то я настоятельно не рекомендую пытать диск своими силами, а доверить восстановление профессионалам
Если же ты уверен, что диск исправен, и ты готов немного рискнуть, то советую тебе начать с замены сата-кабеля и аккуратной чистки контактов (возможно, придется снять плату с диска, если конструкция позволяет)
Если самостоятельно рискнешь и дальше играть фсчеком, то вероятность потери данных будет постепенно приближаться к 1. Возможно, это голословное утвеждение, но я не знаю, в каком состоянии диск, где он стоял, в какой среде (температура, влажность, вибрации) работыл, как часто на него что-то писалось. Я ж даже смарта не видел
Sergey
Еще хочу добавить, что метаданные у ext4 многократно дублируются на диске, и побить их все очень сложно
Sergey
Еще рекомендую сменить ПК, чтобы исключить его программного-аппаратные ошибки, типа разболтанных разъемов и битой памяти
Sergey
там не только чексуммы, оно ещё предлагает "Clear HTree index?" что звучит страшно.
а сделать dd некуда
Насколько я помню, это означает, что некоторые файлы были "потеряны" в пространстве файлов-каталогов, т.е. лишились своей постоянной "прописки" в путях
В случае согласия, такие файлы будут перемещены в каталог lost+found и будут иметь названия из абракадабры
Я не смог быстро найти в интернете что-то подтверждающее, и такое поведение вообще может соответствовать ext3, а не ext4
Советую почитать документацию, т.к. меня память нередко подводит))
Sergey
Еще один вариант
Ты можешь чем-нибудь подсмотреть номера суперблкоков, и скормить их фсчеку по одному. А потом посмотреть, что получится
分解物質
я перепроверил отчёт fsck:
分解物質
чё сообщение удаляется
ElXreno
я перепроверил отчёт fsck:
Лучше заливай его на какой-нибудь paste.centos.org.
Или 0bin.net.
分解物質
и ссылка удаляется
Boris
ElXreno
и ссылка удаляется
Это защита в боте. В качестве костыля, можешь ссылку поделить так, чтобы она не определялась как ссылка, пока тебя не добавят в список разрешённых.
分解物質
А вот кликабельная.
https://paste.centos.org/view/32db7d0b
я так понимаю это значит что потеряных файлов после применения fsck не будет?
分解物質
в интернете такое есть
> Pass 4: Checking reference counts
> Unattached inode 129
> Connect to /lost+found? no
分解物質
хм
分解物質
похоже все ошибки что у меня есть это плохие чексуммы у всех group descriptor и block #xx has bad min hash, block #xx has bad max hash
分解物質
похоже все ошибки что у меня есть это плохие чексуммы у всех group descriptor и block #xx has bad min hash, block #xx has bad max hash
как будто соль для хешей в фс изменилась
分解物質
похоже все ошибки что у меня есть это плохие чексуммы у всех group descriptor и block #xx has bad min hash, block #xx has bad max hash
при этом не одной потерянной иноды
分解物質
блиин
分解物質
у раздела uuid изменился
分解物質
и у меня остался в истории старый uuid
分解物質
и uuid используется во всех хешах и чексуммах
分解物質
вопрос чё он изменился то а
分解物質
втф
分解物質
и почему uuid изменился на такойже как на соседнем диске
Sergey
я так понимаю это значит что потеряных файлов после применения fsck не будет?
Тыщу лет не видел вывода фсчека, не могу сказать
dima
Я не знаю что за хрень ошибка вылезла была ссылка, лень искать что-то с теневыми копиям нахофигачили, мне было проще переустановть
Sergey
Или там был интеловский "физический" в зеркале, который однажды развалился
分解物質
не это два разных диска
Sergey
Ну, тебе виднее
Igor 🇺🇦
Всех с праздником.
Напомните, пожалуйста, с какой версии ядра не работает CUDA
dima
И тебя
Igor 🇺🇦
Говорили как бы с 5.9, но у меня в 5,7,6 работает, а 5,7,10 уже нет
Sergey
Всех с праздником.
Напомните, пожалуйста, с какой версии ядра не работает CUDA
5.9
Но я ее еще не пробовал, подтвежить или опровергнуть не могу
Igor 🇺🇦
5.9
Но я ее еще не пробовал, подтвежить или опровергнуть не могу
А почему тогда у меня так странно...
Sergey
Говорили как бы с 5.9, но у меня в 5,7,6 работает, а 5,7,10 уже нет
Машины с кудой вообще противопоказано обновлять))
Sergey
А почему тогда у меня так странно...
Нуве включается или моудль для 5.7.10 не собрался
Что-то тривиальное скорее всего
分解物質
поменяю.
но тайна остаётся
у проблемного диска вся информация в суперблоке - копия другого диска. вплоть то даты-секунды создания раздела
Igor 🇺🇦
А как-то его собрать? дракут запускал, что ему еще надо?
Sergey
А как-то его собрать? дракут запускал, что ему еще надо?
sudo akmods --force && sudo dracut --force
Igor 🇺🇦
Может видуха уже старая 650, или нет? Какая-то чепуха творится с ними, приличного ничего нету. 210, 710, 1030, 1050 и потом 3060Ти за 1к$
Igor 🇺🇦
А это ещё что? где взять-то?
Sergey
Не, тут про 5.7.10
Sergey
Ты ведь в курсе, что для 390 работает только с определенной версией куды?
Sergey
И для 390 это либо 9.1, либо 9.2 (я точно не помню)
Sergey
Откуда куду ставил, драйвер?
Igor 🇺🇦
nvidia 15835136 437 nvidia_uvm,nvidia_modeset
分解物質
Может быть оно было софтрейдом, а ты и не заметил?
на этих двух дисках есть софтрейд он он объединяет другие разделы
Igor 🇺🇦
Откуда куду ставил, драйвер?
Да из репозитория. Работало до обновы ядра. Потом вообще Блендер перестал запускаться. Удалил новое ядро, Блендер запустился, но КУДА исчезла.
Igor 🇺🇦
Если выбрать самое старое ядро 5,7,6 то КУДА есть, ели же 5,7,10 нету
Igor 🇺🇦
Т.е. она сейчас появляется в зависимости какое ядро при загрузке выбрано
Igor 🇺🇦
Это уже с проблемным ядром?
Сейчас перезагружусь попробую ещё разок. но кажись там тоже все грузится
Sergey
на этих двух дисках есть софтрейд он он объединяет другие разделы
Звучит как начало бессонной ночи))
Sergey
Сейчас перезагружусь попробую ещё разок. но кажись там тоже все грузится
Ну ты даешь))
Нужно было сразу на проблемном
В общем, смотри вывод nvidia-smi, там должен быть 390 драйвер
Если все ок, то устанавливай куду, загрузившись в новое ядро, как описано у нас в факе
Sergey
Насколько я помню, тот способ рабочий, но я его давненько не проверял
Igor 🇺🇦
Ну ты даешь))
Нужно было сразу на проблемном
В общем, смотри вывод nvidia-smi, там должен быть 390 драйвер
Если все ок, то устанавливай куду, загрузившись в новое ядро, как описано у нас в факе
Просто упустил из виду.
$ nvidia-smi
Thu Jan 7 20:19:20 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.138 Driver Version: 390.138 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 650 Ti Off | 00000000:09:00.0 N/A | N/A |
| 23% 28C P8 N/A / N/A | 185MiB / 973MiB | N/A Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 Not Supported |
+-----------------------------------------------------------------------------+
Igor 🇺🇦
Насколько я помню, тот способ рабочий, но я его давненько не проверял
Нету КУДЫ. Сносил её полностью, и снова ставил. Нету и всё
Ugleplastic