- PVSM.RU - https://www.pvsm.ru -
Пару недель назад в версии ядра Linux 5.1 обнаружили баг, который приводил к потере данных на SSD. Недавно разработчики выпустили [1] корректирующий патч Linux 5.1.5, который залатал «брешь».
Обсуждаем, в чем была причина.
[2]
/ Unsplash / Glen Carrie [3]
В начале года разработчики внесли ряд изменений в ядро Linux 5.1. После этого на системах с SSD от компании Samsung, которые используют шифрование dm-crypt/LUKS c device-mapper/LVM, начала проявляться ошибка [4], приводящая к потере данных. Но о проблеме стало известно [5] только в середине мая — тогда же её начали активно обсуждать на тематических форумах [6].
Известно как минимум о двух людях, столкнувшихся с багом, — это участник [7] рассылки LKML [8] Майкл Ласс (Michael Laß), который впервые сообщил о проблеме [5], и пользователь [9] ArchLinux.
Майкл запустил [10] команду fstrim, которая говорит накопителю, какие блоки данных больше не используются, для смонтированного тома btrfs. После он получил следующие системные сообщения:
attempt to access beyond end of device
sda1: rw=16387, want=252755893, limit=250067632
BTRFS warning (device dm-5): failed to trim 1 device(s), last error -5
BTRFS warning (device dm-5): csum failed root 257 ino 16634085 off 21504884736 csum 0xd47cc2a2 expected csum 0xcebd791b mirror 1
После этого он обнаружил, что том btrfs поврежден, а остальные логические тома на физическом устройстве уничтожены.
В случае с пользователем ArchLinux проблема коснулась криптозащиты LUKS. После перезагрузки операционной системы и выполнения fstrim заголовки LUKS (которые используются для поиска томов) оказались нечитаемыми, что не позволило расшифровать зашифрованные данные.
Проблема заключалась в подсистеме device mapper [11] (DM), задача которой — создавать виртуальные блочные устройства. Она как раз используется для реализации менеджера логических томов LVM, программного RAID и системы шифрования дисков dm-crypt.
«Команда fstrim помечала слишком большое количество блоков за раз без учета предела max_io_len_target_boundary. В результате освобождались те сегменты памяти, которые до сих пор используются, — комментирует Сергей Белкин, начальник отдела развития 1cloud.ru [12]. — Поскольку ошибка была связана с device mapper, в теории потеря данных могла произойти на любой файловой системе».
Патч для бага разработчики ядра выпустили в конце мая. Были изменены [13] всего четыре строчки в файле drivers/md/dm.c. Соответствующие изменения также внесли в грядущее ядро Linux 5.2 (добавленные и удаленные строки отмечены знаками «+» и «-» соответственно):
@@ -1467,7 +1467,7 @@ static unsigned get_num_write_zeroes_bios(struct dm_target *ti)
static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti,
unsigned num_bios)
{
- unsigned len = ci->sector_count;
+ unsigned len;
@@ -1478,6 +1478,8 @@ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *
if (!num_bios)
return -EOPNOTSUPP;
+ len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti));
+
__send_duplicate_bios(ci, ti, num_bios, &len);
ci->sector += len;
Патч уже применили разработчики дистрибутивов ArchLinux [14]/Manjaro и Fedora [15]. Дистрибутив Ubuntu ошибка не затронула [6], так как его не переводили на версию ядра Linux 5.1.
/ Flickr / Andy Melton [16] / CC BY-SA
Исключить ситуацию с потерей данных можно и не устанавливая патч. Достаточно отключить сервис fstrim.service/timer с помощью команд:
systemctl disable fstrim.timer
systemctl stop fstrim.timer
Еще вариант — переименовать исполняемый файл fstrim или убрать флаг discard при монтировании fstab. Еще можно выключить режим allow-discards в LUKS через dmsetup. Однако все эти методы не более чем временные и не решают сути проблемы.
Это не первый случай, когда коммит в ядре Linux приводит к ситуациям с memory corruption. Похожая история случалась [17] в версии Linux 4.19 — тогда оказались виноваты планировщики ввода/вывода BLK-MQ. Проблема проявлялась при сборке ядра с опцией CONFIG_SCSI_MQ_DEFAULT=y, выставляемой по умолчанию. В некоторых случаях данные тома оказывались [18] повреждены.
sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107
sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107
Наиболее часто проблема проявлялась с EXT4, но в теории могла затрагивать и другие файловые системы.
Тогда один из мейнтейнеров ядра подготовил небольшой фикс [19], который решал проблему. Однако этот же самый баг позже обнаружили в билде Linux 4.20. Окончательно избавиться [20] от него удалось в конце декабря 2018 с новым глобальным обновлением.
Наши дополнительные ресурсы и источники:
Резервное копирование файлов: как подстраховаться от потери данных [21]
Минимизация рисков: как не потерять ваши данные [22]
Backup&Recovery: поточная и умная дедупликация, снапшоты и вторичное хранение [23]
Как сэкономить с помощью прикладного программного интерфейса [24]
DevOps в облачном сервисе на примере 1cloud.ru [25]
Эволюция архитектуры облака 1cloud [26]Как у нас все устроено: дайджест от 1cloud [27]
Потенциальные атаки на HTTPS и способы защиты от них [28]
Автор: 1cloud
Источник [29]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/320023
Ссылки в тексте:
[1] выпустили: http://lkml.iu.edu/hypermail/linux/kernel/1905.3/01335.html
[2] Image: https://habr.com/ru/company/1cloud/blog/454978/
[3] Glen Carrie: https://unsplash.com/photos/6-XmguXtoVE/
[4] начала проявляться ошибка: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
[5] стало известно: https://www.redhat.com/archives/dm-devel/2019-May/msg00082.html
[6] обсуждать на тематических форумах: https://linustechtips.com/main/topic/1066931-linux-51-kernel-hit-by-ssd-trim-bug-which-causes-massive-data-loss/
[7] участник: https://twitter.com/michael__lass/status/1130881332471427072
[8] LKML: https://en.wikipedia.org/wiki/Linux_kernel_mailing_list
[9] пользователь: https://bbs.archlinux.org/viewtopic.php?id=246569
[10] запустил: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
[11] device mapper: https://ru.wikipedia.org/wiki/Device_mapper
[12] 1cloud.ru: https://1cloud.ru/?utm_source=habrahabr&utm_medium=cpm&utm_campaign=fstrim&utm_content=site
[13] изменены: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.1.y&id=871e122d55e8d1cd7c0d5dec9bdba1fe45406196
[14] ArchLinux: https://www.archlinux.org/packages/core/x86_64/linux/
[15] Fedora: https://koji.fedoraproject.org/koji/buildinfo?buildID=1270326
[16] Andy Melton: https://www.flickr.com/photos/trekkyandy/32411334526/
[17] случалась: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-EXT4-Issue-Likely-MQ
[18] оказывались: https://bugzilla.kernel.org/show_bug.cgi?id=201685
[19] подготовил небольшой фикс: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c255
[20] избавиться: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-4.20-BLK-MQ-Fix
[21] Резервное копирование файлов: как подстраховаться от потери данных: https://1cloud.ru/blog/rezervnoe-kopirovanie-failov?utm_source=habrahabr&utm_medium=cpm&utm_campaign=fstrim&utm_content=blog
[22] Минимизация рисков: как не потерять ваши данные: https://1cloud.ru/blog/minimizazia-it-riskov?utm_source=habrahabr&utm_medium=cpm&utm_campaign=fstrim&utm_content=blog
[23] Backup&Recovery: поточная и умная дедупликация, снапшоты и вторичное хранение: https://1cloud.ru/blog/backup-recovery?utm_source=habrahabr&utm_medium=cpm&utm_campaign=fstrim&utm_content=blog
[24] Как сэкономить с помощью прикладного программного интерфейса: https://1cloud.ru/blog/ekonomiya-na-api?utm_source=habrahabr&utm_medium=cpm&utm_campaign=jmap&utm_content=blog
[25] DevOps в облачном сервисе на примере 1cloud.ru: https://1cloud.ru/blog/devops-v-razrabotke-oblaka-1cloud?utm_source=habrahabr&utm_medium=cpm&utm_campaign=jmap&utm_content=blog
[26] Эволюция архитектуры облака 1cloud: https://1cloud.ru/blog/our-system-architecture-evolution?utm_source=habrahabr&utm_medium=cpm&utm_campaign=jmap&utm_content=blog
[27] Как у нас все устроено: дайджест от 1cloud: https://www.facebook.com/1cloudru/posts/2320833768239130
[28] Потенциальные атаки на HTTPS и способы защиты от них: https://www.facebook.com/1cloudru/photos/a.1526614574327724/2317948435194330/
[29] Источник: https://habr.com/ru/post/454978/?utm_campaign=454978&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.