Ну вот мы и видим этот самый слух про место для рута в действии, ага. А меж тем, думать полезно.
да, именно так, тока резервируется не потому что скоорость может упасть, а для того чтобы привилегированные процессы (типа syslog ) не создавали дефрагментацию
Фрагментацию тогда уж, а не
дефрагментацию.
Всё гораздо проще. При исчерпании места на диске простым усером (и не только) система (для непривилегированного пользователя) становится колом. Даже залогиниться усер (простой) не сможет.
Для этого и создаётся резерв (по умолчанию на ext2/3 он составляет 5%), доступный только для root, дабы он почистить/расклинить систему мог. Ну и дабы сислог и привилегированные процессы нормально работали.
Опять же, тот же слух, а стоило бы копнуть глубже. Тот же syslog работает под рутом - вот он переполнит раздел невзирая на резерв, и что? Кстати, нормальной практикой безопасности является PermitRootLogin no в sshd_config, так что один фиг колом.
Далее, этот резерв при желании элементарно (шо означает и вероятность случайного непредумышленного) обходится простым юзером, простейший способ ping 127.0.0.1 > /path/file_on_partition_to_overflow и подождать. Другие способы в свое время рассматривались в рассылке lkml (linux-kernel), там же и сошлись на том, что это нифига не фича для безопасности, не поддерживается, рассчитывать на неё нельзя (используйте квоты), и что неплохо бы исправить документацию на эту тему, но всем было лень.
Происходит же он от того, что как раз при большой заполненности диска алгоритмы размещения блоков начинают работать хуже, как раз усиливается фрагментация (найти свободные куски достаточного размера всё сложнее), и как результат - падает производительность записи. В интернете можно найти рекомендации делать этот резерв даже больше, 10% (иногда и более) - по некоторым замерам, ниже этого порога производительность может упасть до 2 раз. Разумеется, всё это зависит от паттерна использования раздела - я на серверах на разделы с редкой записью делаю -m 0, некритично. На UFS он по умолчанию равен 8% (её структуры и алгоритмы несколько сложнее, чем на ext2).
Ну и наконец, стандартная документация mkfs.ext2 и документация ядра всё-таки упоминают проблему фргаментации, хоть и не были исправлены, чтобы прояснить вопрос окончательно. В конце концов, если бы предназначение этой фичи было лишь резервом места, то она присутствовала бы во всех файловых системах, либо вообще не в fs, а на уровне регулятора в /proc. Однако мы не видим её ни в Райзере, ни в XFS, и т.д., а только лишь в файловых системах со структурой и алгоритмами семейства ufs/ext2/ext3, что еще раз подтверждает зависимость от конкретных проблем конкретных FS.
