Изучите возможность записи на диск, чтобы выяснить, какой процесс записывает данные на мой SSD

Вы могли бы по крайней мере начать с iotop. Он не скажет вам, какая файловая система пишется, но даст вам некоторые процессы для исследования.

sudo apt-get install iotop
sudo iotop

Показывает мгновенное чтение и запись на диск и название команды чтения или записи.

Если вы пытаетесь перехватить процесс, который пишет редко, вы можете использовать опцию --accumulate или записать вывод в файл:

sudo -i
iotop --batch > iotop_log_file

Очевидно, что запись файла журнала будет отображаться в результатах, но вы также должны иметь возможность grep для других процессов записи на диск.

К этому моменту вы сможете найти несколько возможных подозрительных процессов. Левый столбец в iotop показывает pid. Затем выясните, в какой файловый дескриптор записывает процесс:

sudo -i
strace -p <pid> 2>&1 | grep write

Вывод будет выглядеть следующим образом, когда процесс пишет:

write(1, "\n", 1)                       = 1
write(4, "test\n", 5)                   = 5
write(1, ">>> ", 4)                     = 4

Первый аргумент для записи - это файл дескриптор. Вероятно, мы ищем значения больше 2, потому что 0, 1 и 2 - это просто stdin, stdout и stderr. Файловый дескриптор 4 выглядит интересно.

Теперь вы можете узнать, на какой файл указывает дескриптор файла:

lsof -p <pid>

, который должен выдавать результат, например:

...
python  23908  rob  mem    REG    8,1    26258 8392656 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
python  23908  rob    0u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    1u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    2u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    3w   REG   0,25      909 9049082 /home/rob/testfile
python  23908  rob    4w   REG   0,25       20 9049087 /home/rob/another_test_file

Посмотрите на 4-й столбец. 4w означает, что файловый дескриптор 4 открыт для записи, а файл - another_test_file.

Возможно, процесс открывает, записывает и затем закрывает файл, и в этом случае lsof не показывает его. Вы можете заметить, что это происходит с:

strace -p <pid> 2>&1 | grep open

Далее используется механизм дампа блока виртуальной памяти ядра. Сначала получите скрипт perl:

wget https://raw.githubusercontent.com/true/aspersa-mirror/master/iodump

Затем включите дамп блока:

echo 1 | sudo tee /proc/sys/vm/block_dump

И выполните следующее:

while true; do sleep 1; sudo dmesg -c; done  | perl iodump

.. и нажмите Управляя c , чтобы закончить, вы увидите что-то вроде следующего:

^C# Caught SIGINT.
TASK                   PID      TOTAL       READ      WRITE      DIRTY DEVICES
jbd2/sda3-8            620         40          0         40          0 sda3
jbd2/sda1-8            323         21          0         21          0 sda1
#1                    4746         11          0         11          0 sda3
flush-8:0             2759          7          0          7          0 sda1, sda3
command-not-fou       9703          4          4          0          0 sda1
mpegaudioparse8       8167          2          2          0          0 sda3
bash                  9704          1          1          0          0 sda1
bash                  9489          1          0          1          0 sda3
mount.ecryptfs_       9698          1          1          0          0 sda1

И отключите дамп блока, когда закончите:

echo 0 | sudo tee /proc/sys/vm/block_dump

Благодарю http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/ за эту полезную информацию. Информация.