Является ли создание дампа ядра атомарной операцией?
Вы можете проверить текущее состояние массива с помощью cat / proc / mdstat . В этом примере данные берутся отсюда.
Итак, предположим, что у нас есть md127 с 3 дисками в raid1. Здесь это просто разделы одного диска, но это не имеет значения.
md127 : active raid1 vdb3[2] vdb2[1] vdb1[0]
102272 blocks super 1.2 [3/3] [UUU]
Нам нужно отключить один из дисков, прежде чем мы сможем его удалить:
$ sudo mdadm --manage /dev/md127 --fail /dev/vdb2
mdadm: set /dev/vdb2 faulty in /dev/md127
И статус теперь показывает, что он плохой
md127 : active raid1 vdb3[2] vdb2[1](F) vdb1[0]
102272 blocks super 1.2 [3/2] [U_U]
Теперь мы можем удалить этот диск:
$ sudo mdadm --manage /dev/md127 --remove /dev/vdb2
mdadm: hot removed /dev/vdb2 from /dev/md127
md127 : active raid1 vdb3[2] vdb1[0]
102272 blocks super 1.2 [3/2] [U_U]
А теперь измените размер:
$ sudo mdadm --grow /dev/md127 --raid-devices=2
raid_disks for /dev/md127 set to 2
unfreeze
На этом этапе мы успешно уменьшили массив до 2 дисков:
md127 : active raid1 vdb3[2] vdb1[0]
102272 blocks super 1.2 [2/2] [UU]
Итак, теперь новый диск можно повторно добавить в качестве горячей замены:
$ sudo mdadm -a /dev/md127 /dev/vdb2
mdadm: added /dev/vdb2
md127 : active raid1 vdb2[3](S) vdb3[2] vdb1[0]
102272 blocks super 1.2 [2/2] [UU]
(S) показывает, что это горячая запчасть.
Мы можем убедиться, что это работает должным образом, выйдя из строя существующий диск и заметив, что на резервном диске происходит перестройка:
$ sudo mdadm --manage /dev/md127 --fail /dev/vdb1
mdadm: set /dev/vdb1 faulty in /dev/md127
md127 : active raid1 vdb2[3] vdb3[2] vdb1[0](F)
102272 blocks super 1.2 [2/1] [_U]
[=======>.............] recovery = 37.5% (38400/102272) finish=0.0min speed=38400K/sec
vdb2 больше не помечен (S) , потому что это не горячая замена .
После повторного добавления поврежденного диска он теперь помечен как горячий
md127 : active raid1 vdb1[4](S) vdb2[3] vdb3[2]
102272 blocks super 1.2 [2/2] [UU]
Я бы на это не рассчитывал, особенно на загруженной многопоточной системе, или если местоположение дампа находится на сетевом ресурсе (помню, как один профессор создавал файлы ядра размером 8 Гб, которые приходилось передавать по 10 Мбит ethernet через NFS). Атомарность файловой системы обычно требует блокировки или трюка write-to-a-temporary-file-and-then-rename(1). Некоторое изучение fs/coredump.c для ядра linux 4.3.3 указывает на отсутствие таких трюков с блокировкой или переименованием, так как ядро определяет имя файла, который нужно использовать (с условием гонки отсоединения! ) и затем рассылает файл:
file_start_write(cprm.file);
core_dumped = binfmt->core_dump(&cprm);
file_end_write(cprm.file);
Поскольку, вероятно, нет гигантской блокировки ядра, чтобы предотвратить запуск других пользовательских вещей, пока вышеупомянутое делает свое дело (это можно проверить, замедлив генерацию большого файла ядра и посмотрев, как ведет себя эта система), я не вижу ничего атомарного в этом процессе.
Нет, как и любой другой файл, он появляется в файловой системе в момент начала записи, а не после завершения и закрытия.