Почитал замечательную статью про багу в ядре от коллег из PostgresPro, где сошлись воедино XFS и безопасность, спойлерить сильно не буду, замечательный детектив. А вспомнить на этом фоне хочется важные для этой пьесы параметры ядра init_on_free + init_on_alloc. Если кратко - ради безопасности решили на каждой аллокации и на каждом освобождении страницы памяти её занулять, по дефолту это начали включать примероно в 2020м году, или в районе ядра 5.3. На бумаге всё хорошо, прибираем за нерадивыми разработчиками утёкшую информацию из памяти. А вот по перформансу даже оригинальное описание патча немного расходится: The slowdown for init_on_free=0, init_on_alloc=0 compared to the baseline is within the standard error. , при этом немного ниже: Although init_on_free is rather costly, there are paranoid use-cases where in-memory data lifetime is desired to be minimized. Самая интересная часть - а зачем это вообще надо: There are various arguments for/against the realism of the associated threat models, but given that we'll need the infrastructure for MTE anyway, and there are people who want wipe-on-free behavior no matter what the performance cost, it seems reasonable to include it in this series. И вот так, лёгким мановением руки, патч для тех, who want wipe-on-free behavior no matter what the performance cost, заезжает в мастер и включается в подавляющем количестве дистрибутивов по дефолту. Для ZFS, к примеру, в самом начале это аукнулось деградацией перформанса до 40%! Самое неприятное, что фактические проблемы с перфом хорошо видны только при полноценной загрузке канала до ОЗУ, и многие начинают этим пренебрегать. В общем - ещё несколько параметров в копилку настроек, которые меня соблазняют их отключить. 💩 - такая безопасность == "дышать вредно" 🦄 - безопасность важнее, торопиться некуда 🤡 - ох уж эти кликбейтные эмодзи-голосования