Комментарии 12
Используйте LVM и ваши разделы будут пушистые и шелковистые
можно в fstab прописать.
PS: dd лучше делать не с bs=1G count=1, а bs=1M count=1024
PS: dd лучше делать не с bs=1G count=1, а bs=1M count=1024
> фрагментация — не такая большая проблема в никсовых ФС
это заблуждение
rus-linux.net/lib.php?name=MyLDP/file-sys/ext3/ext3fs-5.html
это заблуждение
rus-linux.net/lib.php?name=MyLDP/file-sys/ext3/ext3fs-5.html
> Размер запросто можно изменить
С современными объёмами ОЗУ, можно вообще обойтись без подкачки. Зачем вам 1 гигабайт подкачки, если у вас 3 Гб ОЗУ, которые фактически наполовину заняты кэшем диска (т.е. кэшируют в том числе ту же подкачку)?
Теоретически, при необходимости в любой момент легко можно создать файл для подкчаки. (На практике, такая необходимость не возникнет.)
> фрагментация — не такая большая проблема в никсовых ФС
Повлияет фрагментация на момент создания файла, а это вы будете делать, вероятно, в начале эксплуатации системы, т.е. на свободном диске, и не получите значительной фрагментации.
На самом деле, это вовсе не единственная причина тормозов файла подкачки. Дело в том, что вряд ли вы станете делать не-журналируемую файловую систему, верно? Всё, что пишется в файловую систему, проходит через журнал, т.е. пишется на диск дважды. Файл подкачки — вовсе не исключение, и журналирование может повлиять на скорость работы подкачки сильнее, чем фрагментация.
И это не гипотетическая ситуация — почти во всех дистрибутивах по умолчанию используется файловая система ext3 с режимом journal_data, и эффект будет наблюдаться в полной мере.
Если вы вздумаете потом ещё и увеличить размер файла подкачки, получите вдобавок ещё и фрагментацию.
Кроме того, вы, видимо, никогда не поднимали Linux Software RAID. Здесь тоже имеются определённые особенности, и, конечно, выгоднее использовать именно раздел(ы) подкачки.
> меБИбайтов
Ах, какой вы умный.
С современными объёмами ОЗУ, можно вообще обойтись без подкачки. Зачем вам 1 гигабайт подкачки, если у вас 3 Гб ОЗУ, которые фактически наполовину заняты кэшем диска (т.е. кэшируют в том числе ту же подкачку)?
Теоретически, при необходимости в любой момент легко можно создать файл для подкчаки. (На практике, такая необходимость не возникнет.)
> фрагментация — не такая большая проблема в никсовых ФС
Повлияет фрагментация на момент создания файла, а это вы будете делать, вероятно, в начале эксплуатации системы, т.е. на свободном диске, и не получите значительной фрагментации.
На самом деле, это вовсе не единственная причина тормозов файла подкачки. Дело в том, что вряд ли вы станете делать не-журналируемую файловую систему, верно? Всё, что пишется в файловую систему, проходит через журнал, т.е. пишется на диск дважды. Файл подкачки — вовсе не исключение, и журналирование может повлиять на скорость работы подкачки сильнее, чем фрагментация.
И это не гипотетическая ситуация — почти во всех дистрибутивах по умолчанию используется файловая система ext3 с режимом journal_data, и эффект будет наблюдаться в полной мере.
Если вы вздумаете потом ещё и увеличить размер файла подкачки, получите вдобавок ещё и фрагментацию.
Кроме того, вы, видимо, никогда не поднимали Linux Software RAID. Здесь тоже имеются определённые особенности, и, конечно, выгоднее использовать именно раздел(ы) подкачки.
> меБИбайтов
Ах, какой вы умный.
Чёрт, промахнулся мимо галочки. Зато плюсанул в карму ;)
Всё правильно пишете :)
Всё правильно пишете :)
НЛО прилетело и опубликовало эту надпись здесь
Имел ввиду, что выпячивание этих «правильных бинарных приставок» показывает не образованность, а скорее презрение к традициям информатики.
Тут, правда, оно может быть оправдано именно необходимостью различения. У программы dd единицы измерения обозваны по-марсиански (K для 1024 и KB для 1000 — совершенно не очевидно), так что можно использовать и марсианские бинарные приставки.
Тут, правда, оно может быть оправдано именно необходимостью различения. У программы dd единицы измерения обозваны по-марсиански (K для 1024 и KB для 1000 — совершенно не очевидно), так что можно использовать и марсианские бинарные приставки.
Без подкачки обойтись нельзя в некоторых случаях, когда рост нагрузки просчитать невозможно
Вдруг в пике нужно будет 4GB? А есть только 3G?
Вот тогда и подкачка поможет избежать OOM
Вдруг в пике нужно будет 4GB? А есть только 3G?
Вот тогда и подкачка поможет избежать OOM
>Теоретический недостаток — замедленный доступ к файлу из-за фрагментации файловой системы, на которой он находится (всего лишь теоретический, поскольку фрагментация — не такая большая проблема в никсовых ФС).
Говорите за себя!
В Linux фрагментация ФС — большая проблема, потому что Ext3 (которая родная) не умеет распределять кусочки неполностью заполненных блоков. Уровень фрагментации Ext2/Ext3 достигает 20-30% на раздел — конечно, меньше, чем у NTFS, но всё равно заметно. Только в Ext4 и других портированных на Linux файловых системах эта проблема решена.
К примеру, FreeBSD'шная UFS2 распределяет дисковое пространство не только на уровне блоков, но и на уровне фрагментов блоков. Поэтому фрагментация после интенсивных дисковых операций на UFS2 никогда не превашает 3-5%. А техника мягких обновлений (Soft Updates) делает ненужным журнал метаданных на диске, что тоже способствует уменьшению фрагментации.
Говорите за себя!
В Linux фрагментация ФС — большая проблема, потому что Ext3 (которая родная) не умеет распределять кусочки неполностью заполненных блоков. Уровень фрагментации Ext2/Ext3 достигает 20-30% на раздел — конечно, меньше, чем у NTFS, но всё равно заметно. Только в Ext4 и других портированных на Linux файловых системах эта проблема решена.
К примеру, FreeBSD'шная UFS2 распределяет дисковое пространство не только на уровне блоков, но и на уровне фрагментов блоков. Поэтому фрагментация после интенсивных дисковых операций на UFS2 никогда не превашает 3-5%. А техника мягких обновлений (Soft Updates) делает ненужным журнал метаданных на диске, что тоже способствует уменьшению фрагментации.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование файла подкачки вместо раздела