> Размер запросто можно изменить
С современными объёмами ОЗУ, можно вообще обойтись без подкачки. Зачем вам 1 гигабайт подкачки, если у вас 3 Гб ОЗУ, которые фактически наполовину заняты кэшем диска (т.е. кэшируют в том числе ту же подкачку)?
Теоретически, при необходимости в любой момент легко можно создать файл для подкчаки. (На практике, такая необходимость не возникнет.)
> фрагментация — не такая большая проблема в никсовых ФС
Повлияет фрагментация на момент создания файла, а это вы будете делать, вероятно, в начале эксплуатации системы, т.е. на свободном диске, и не получите значительной фрагментации.
На самом деле, это вовсе не единственная причина тормозов файла подкачки. Дело в том, что вряд ли вы станете делать не-журналируемую файловую систему, верно? Всё, что пишется в файловую систему, проходит через журнал, т.е. пишется на диск дважды. Файл подкачки — вовсе не исключение, и журналирование может повлиять на скорость работы подкачки сильнее, чем фрагментация.
И это не гипотетическая ситуация — почти во всех дистрибутивах по умолчанию используется файловая система ext3 с режимом journal_data, и эффект будет наблюдаться в полной мере.
Если вы вздумаете потом ещё и увеличить размер файла подкачки, получите вдобавок ещё и фрагментацию.
Кроме того, вы, видимо, никогда не поднимали Linux Software RAID. Здесь тоже имеются определённые особенности, и, конечно, выгоднее использовать именно раздел(ы) подкачки.
Имел ввиду, что выпячивание этих «правильных бинарных приставок» показывает не образованность, а скорее презрение к традициям информатики.
Тут, правда, оно может быть оправдано именно необходимостью различения. У программы dd единицы измерения обозваны по-марсиански (K для 1024 и KB для 1000 — совершенно не очевидно), так что можно использовать и марсианские бинарные приставки.
Без подкачки обойтись нельзя в некоторых случаях, когда рост нагрузки просчитать невозможно
Вдруг в пике нужно будет 4GB? А есть только 3G?
Вот тогда и подкачка поможет избежать OOM
>Теоретический недостаток — замедленный доступ к файлу из-за фрагментации файловой системы, на которой он находится (всего лишь теоретический, поскольку фрагментация — не такая большая проблема в никсовых ФС).
Говорите за себя!
В Linux фрагментация ФС — большая проблема, потому что Ext3 (которая родная) не умеет распределять кусочки неполностью заполненных блоков. Уровень фрагментации Ext2/Ext3 достигает 20-30% на раздел — конечно, меньше, чем у NTFS, но всё равно заметно. Только в Ext4 и других портированных на Linux файловых системах эта проблема решена.
К примеру, FreeBSD'шная UFS2 распределяет дисковое пространство не только на уровне блоков, но и на уровне фрагментов блоков. Поэтому фрагментация после интенсивных дисковых операций на UFS2 никогда не превашает 3-5%. А техника мягких обновлений (Soft Updates) делает ненужным журнал метаданных на диске, что тоже способствует уменьшению фрагментации.
Использование файла подкачки вместо раздела