Зависание linux с ошибкой записи на SSD диск

Все пользователи линукс знают, что зависание системы - это что-то очень экстраординарное. Можно месяцами не перезагружать компьютер, и он будет работать без нареканий. Поэтому когда у меня ни с того, ни с сего начал зависать компьютер с linux mint 20.2, я в первую очередь подумал, что что-то случилось с железом.

При этом иногда компьютер просто зависал, а иногда вываливался с кучей ошибок  записи на корневой раздел и на раздел с /usr ((эти 2 раздела у меня на SSD диске, /home - на жестком диске, такая разбивка показалась мне надежнее). Ошибка была про системный журнал ext4, itable и ошибки чтения записи (точный текст ошибки не помню).   

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

Проверки с помощью badblocks и smartmontools ничего не дали - ошибок не было, битых блоков тоже. 

Перезагрузил систему  с live USB и попробовал дать команду

sudo fdisk -l # identify all "Linux Filesystem" partitions

sudo e2fsck -fcky /dev/sdXX # read-only test

or

sudo e2fsck -fccky /dev/sdXX # non-destructive read/write test (recommended)

проверил корневой / раздел, утилита что-то там проверила и внесла изменения на диск. После этого диск перестал определяться вообще, даже в bios! Перезагрузка не помогла. Я думал уже, что угробил диск этой утилитой. Но после включения-выключения диск в bios появился и система стала снова загружаться, правда, ненадолго, зависания продолжились.  

Я уже подумал, что пора менят SSD и даже сходил в магазин, купил и поставил его рядом со старым. Решил дать последний шанс старому диску, снова перезагрузился в live USB и еще раз дал команду выше для корневого раздела. В этом раз проверка прошла, изменения были внесены, но диск из системы не пропал. Поэтому проверил еще и /usr - там тоже были найдены какие-то ошибки. 

После перезагрузки поробовал обновить систему - и о чудо! - система обновилась без ошибок. Удалил все лишние ядра, перезагрузился, и все заработало!

Скорее всего был сбой в таблице файлов, который удалось исправить. Продолжаю работать на старом SSD диске.      

Команда с параметрами была взята отсюда (это оказалось лучшим набором параметров для e2fsck)

Описание параметров команды

The -k is important, because it saves the previous bad block table, and adds any new bad blocks to that table. Without -k, you loose all of the prior bad block information.

The -fccky parameter...

   -f    Force checking even if the file system seems clean.

   -c    This option causes e2fsck to use badblocks(8) program to do
         a read-only scan of the device in order to find any bad blocks.
         If any bad blocks are found, they are added to the bad block
         inode to prevent them from being allocated to a file or direc‐
         tory.  If this option is specified twice,  then the bad block scan
         will be done using a non-destructive read-write test.

   -k    When combined with the -c option, any existing bad blocks in the
         bad blocks list are preserved, and any new bad blocks found by
         running badblocks(8) will be added to the existing bad blocks
         list.

   -y    Assume an answer of `yes' to all questions; allows e2fsck to be
         used non-interactively.  This option may not be specified at the
         same time as the -n or -p options.