Уход от low VM conditions
А чего это мы все говорим о достоинствах? Фактом является то, что tmpfs динамически растет и уменьшается. Поэтому естественен провокационный вопрос. А что случится, если tmpfs filesystem разрастется так, что поглотит всю виртуальную память? Скажем так, приемлемое решение еще не найдено. С ядром 2.4.4, увы, произошло бы зависание. С ядром 2.4.6, подсистема VM имеет некоторую защиту, и авария не произойдет. Когда 2.4.6 почувствует точку, за которой ассигнование дополнительной памяти проблематично, вы просто не сможете ничего более записать в tmpfs filesystem. Кроме того, произойдут некоторые другие вещи. Сначала процессы в системе не смогут ассигновать дополнительную память; внешне система станет очень вялой. У суперпользователя есть время, чтобы предпринять шаги для выхода из low-VM condition.
Далее, ядро имеет встроенную last-ditch систему освобождения памяти при ее исчерпании; она находит процесс, который наиболее "жадно" потребляет VM ресурсы и уничтожает его. К сожалению, такое "kill a process" решение имеет неприятные последствия, особенно, если в истощении памяти виновата tmpfs. Причина вот в чем. Сама tmpfs уничтожена быть не может, так как она - часть ядра, а не пользовательский процесс. Кроме того, специфика tmpfs такова, что для ядра не существует простого способа выяснить, какой именно процесс "затопляет" tmpfs. В таких случаях ядро ("вот разберусь до конца и накажу, кого попало") по ошибке "убивает" самый большой VM-hog процесс, которым обычно является ваш X server. Определить, что истинной причиной "падения" X было low-VM condition (tmpfs) очень сложно.
