Как стать автором
Обновить

Комментарии 296

Лично я всегда потом мучился с кучей этих разделов при замене диска, к примеру, либо при забивании одного раздела, хотя на другом еще куча места.
А разве lvm не решает эту проблему?
А зачем создавать проблему, которую потом надо решать? Да и lvm дома — лишняя сущность.
А мне понравился lvm дома. Можно «на живую» переезжать с одного винта на другой.
Попробуйте zfs. Понравится ещё больше.
btrfs muti-device filesystem же.
То есть отформатировать / с сохранением /home больше не получится?
Нафиг-нафиг такое, хоть дома хоть где. Особенно в свете экспериментов с ядром…
НЛО прилетело и опубликовало эту надпись здесь
Ну, так это не вредно. В том смысле, что для железки никакого вреда тут нет.

Касательно смысла — тут всё зависит от целей. Если под домашним ПК подразумевается исключительно некая медиа станция с возможностью серфинга и работы с офисным пакетом, то наверное, да.
Странная у вас аргументация. Мучаетесь вы, а вред компьютеру?
Если вы заранее не можете спланировать таблицу разделов, то используйте lvm.
А какой вред компьютеру-то?
Это я у вас спрашиваю.
У меня долгое время была такая схема:

Есть разделы для:

/ — система, (ext4, от 10 Гб до 20 Гб)
/boot (ext2, до 1 Гб)
/home (ext4, до 20 Гб)
/media/media (почти всё остальное место)

Сейчас, после покупки SSD сетап другой, / и /home переместились в зашифрованный LVM на SSD. /boot тоже на SSD, вне LVM.

При этом, для экспериментов выделялись отдельные разделы, и я, например, мог поставить рядом системы для экспериментов и легко загружаться в любую из них, оставляя все свои данные и настройки приложений из home на месте.

Директории, которые занимают больше всего места в home, такие как, Видео, Изображения и Файлы и так далее, являются просто симлинками на соответствующие директории в /media/media. Директории типа Загрузки и Документы находятся в home, на SSD, т.к. он зашифрован.

Проблем с местом нет. Если места нет, то его нет нигде. :) Зато этот сетап пережил несколько переустановок системы вообще без всяких проблем. Например, после апгрейда, приведшего к большому числу багов было решено сделать откат к предыдущей версии системы. Дело было реализовано за 20 минут.

Так что не надо рассказывать про ненужность и вредность. Если с умом подходить к этому — проблем от этого ноль, зато плюсов — полно.
Это было бы актуально, если бы я занимался какими-то мифическими «экспериментами» и переустановками. Но увы, у меня прошла эта пора.
Ваш юзкейс был бы актуален, если бы на дворе был 2000й год, а VirtualBox был бы еще не написан.
Ставлю все на один раздел, когда покупаю новый винт просто копирую этот раздел (таки на живую, просто делаю remount / -o,ro) на новый винт, расширяю под все пространство и все. Зачем мне что-то еще? Никто так этого и не смог объяснить.
НЛО прилетело и опубликовало эту надпись здесь
А куда же у меня, интересно, пропадет /home при обновлении уже установленного дистрибутива?
Или вы предлагаете каждый раз сносить все полностью и устанавливать заного?
Если вы не уверены в результате обновления или если результат оказался печальным, то это проще всего. И проще удалять файлы с помощью mkfs при заранее продуманном их распределении по блочным устройствам, чем думать, что надо указать rm, а что не надо.
В теории, знаете ли, нет разницы между теорией и практикой. А на практике — есть.

Например, на askubuntu.com правильно пишут: «upgrading Ubuntu works 99 times out of 100». Апгрейд Ubuntu 12.04LTS -> 13.10 (минуя 12.10 и 13.04) превратил одну известную мне систему в овощ, неспособный к запуску половины демонов, включая gnome-session. Переустановка помогла. Так что я бы рекомендовал не только /home хранить отдельно, а ещё и вывод dpkg --get-selections перед апгрейдом сохранять куда-нибудь.

С другими дистрибутивами, подозреваю, дела обстоят ничуть не лучше.
На моей памяти ни разу ubuntu после обновления (например, 12 -> 13) не вела себя как свежеустановленная система или хотя бы не хуже этой же системы до обновления. Почему-то всегда вылезали какие-то проблемы, когда больше, когда меньше, и проще было форматнуть / и переустановить систему не форматируя /home — 30 минут работы (с учётом скачивания дистрибутива и записи на флешку) и получаем свежеустановленную почти полностью настроенную систему.
Не помню такого в своей Gentoo. Вот медленное замусоривание, после которого проще переустановить, чем найти источники проблем — может быть. Особенно, если вы не очень опытный пользователь. Rolling release имеет свои преимущества: с ним очень сложно устроить большие проблемы при обновлении.

Я, кстати, весь /etc засунул под контроль mercurial. И поместил туда /var/lib/portage/world (оставив на прежнем месте symlink, т.к. это чуть ли не единственная принципиально не настраиваемая локация) (debian’овские --get-selections в Gentoo изначально удобно расположились в отдельном текстовом файле).
А /etc под hg запихнуть — интересная идея. Сам сижу на arch'е (выше про убунту — это скорее наблюдение со стороны и последующая помощь в возврате системы к жизни :) ), конфиги тут сами по себе не меняются, а вот чтобы свои бекапы при серьёзных изменениях не плодить использование cvs может оказаться удобным/полезным…
не мучайтесь, давно есть утилита etckeeper
Ну она точно так же использует hg/git/bzr/… и имеет набор хуков для менеджеров пакетов в разных дистрибутивах. Мне проще/понятней будет самому выполнять commit :). А так как пока меня подход заинтересовал исключительно в плане содержимого конфигов, то действительно для меня проще напрямую использовать привычную vcs.
Я уже вроде где‐то отвечал, почему она не подходит. Сейчас не помню всего, но одно нашёл точно — судя по коду при изменении настроек пакетным менеджером etckeeper делает commit. Мне это не нужно нафиг: я веду две ветки — одну с настройками по‐умолчанию, другую с собственными изменениями; после (пере)установок/обновлений делается commit в default и merge. И именно из‐за merge я держу там mercurial: откат мне практически никогда не требовался: большинство настроек легко откатываются либо по памяти, либо с использованием Vim с его persistent undo (ещё больше настроек заменяются на другие верные при обнаружении проблем после их изменения, а не откатываются).

Ещё, как я понял, он делает commit перед запускам пакетного менеджера. Такая самостоятельность мне тоже совершенно не нужна — в /etc часто есть изменения, которые я собираюсь откатить (т.к. это тестовые изменения/временный хак для исправления проблемы и т.д.), и «грязный» hg status мне служит для этого напоминанием. Это оказалось приятным дополнением к merge.
Я не знаю, как при обновлении ПО могут не обновиться настройки по‐умолчанию. Portage не трогает настройки, если они защищены, либо были изменены пользователем, но он всегда кладёт файлы со специальным именем с новыми настройками по‐умолчанию (или со старыми — он их не различает, что меня раньше изрядно злило) и напоминает про них при каждом запуске emerge. Мой скрипт позволяет мне сделать merge того, что положил portage и того, что имею я, ведя две ветки /etc в трёх каталогах (сам /etc, tip моей ветки без изменений в рабочем каталоге и tip ветки с настройками по‐умолчанию: существуют по техническим причинам (так намного проще скриптом сохранять настройки и делать merge)).

Сам скрипт здесь: bitbucket.org/ZyX_I/update-script. Сразу предупреждаю: медленный на множестве изменений, не поддерживает откат при <C-c> (вам придётся шастать по всем трём каталогам, откатывая изменения, если вы не подумали перед запуском) и при указании конкретных файлов для обновления требует указать --none, иначе будет спрашивать вас про все не указанный файлы. И я даже не пытался прикрутить автоматическое обновление после запуска emerge. Меня пока более‐менее устраивает.
НЛО прилетело и опубликовало эту надпись здесь
Я приводил пример с неудачным апгрейдом и откатом назад (причём откат был даже не к предыдущей версии). Причём, в чистой системе (в виртуалбоксе или в живой сессии) некоторых проблем не было, так что обезопасить себя без реальной установки было невозможно.

А скопировать диск при апгрейде харда — как-то особой разницы нет сколько разделов копировать. Ну подумаешь, выполнить не одну команду, а три.
Столкнулся с проблемой того что за 8 лет требования на свободное место СИЛЬНО изменились. И если в 2006 мне хватало 1-2 ГБ на /usr то сегодня он занимает у меня 15. И что мне, раз в несколько лет все это пересоздавать, расширять, двигать итд итп? Зачем? За 8 лет от этого были только проблемы.
А скопировать диск при апгрейде харда — как-то особой разницы нет сколько разделов копировать. Ну подумаешь, выполнить не одну команду, а три.


Если правильно смонтировать разделы нового и старого винта, то скопировать можно и одной командой cp -rav. Сам так дважды перезжал, пруф
Странная у вас аргументация. С разделами мучались вы, а вред компьютеру? Это как?
Если вы заранее не можете спланировать таблицу разделов, то используйте lvm. Заодно и переезжать проще будет.
P.S. Дополню ваш workaround c большими тяжёлыми директориями на харде в /mnt. Можно весь «тяжеляк» (~/Downloads, ~/Video, ~/Music, etc.) вынести симлинками на оную точку монтирования. Ладнее и проще, да и восстанавливать быстрее.
Объясните, зачем вы советуете использовать 32-разрядную систему? Даже если установлено не более 4 гигабайт памяти, зачем использовать 32 бита? Да, вопрос не в том, зачем использовать 64-разрядную систему, а в том, зачем 32-разрядную. 21 век блин на дворе уже давно, а вы свои пережитки всё тащите и тащите. Ну и про PAE — а вы в курсе, что PAE замедляет работу с памятью?
Вернее, не советуете, а пишите, что кроме большего объёма адресуемой памяти преимуществ нет
Не знаю, где вы это прочитали, я наоборот всеми руками за 64 бита.
Я про это:
>От производительности оперативной памяти мало что зависит, от нее не увеличится FPS в играх и не станут быстрее запускаться приложения. Использование 64-битных приложений тоже не дает никакого прироста для обычных задач, только для очень специфичных математических расчетов и операций архивирования. Также, использование 64 ядра не требуется для адресации более 4 ГБ памяти, PAE позволяет адресовать до 64 ГБ памяти на 32 битной системе.

Не использование PAE даёт прирост в производительности при работе с памятью. Я уже не говорю про различные multimedia задачи. То есть, от использования 64-бит выгода есть всегда, даже если памяти меньше 4Gb.
Ну да, дает какой-то сферический прирост. Только ни в играх, ни обычной работе я его так и не заметил.
А про мультимедиа задачи можно пруфы?
Ожидаемо. Как я и говорил, в играх эффекта почти нет.
В общем-то беседа ушла куда-то не туда. Я уже говорил — всеми руками за 64 бита.
Я, например, вообще в игры не играю. А для вас домашний десктоп — это только игры?
Это максимум, что может его загрузить. А что еще? Браузер? Офисный софт? VirtualBox? Eclipse? Для этого всего мне хватает и одноядерного нотбука 8 летней давности.
Не забывайте, что прогрессу ПК (особенно видеоадаптеров) в 00х мы обязаны почти полностью играм.
А как же кодирование видео? Да даже mp3, если в больших количествах, будет заметна разница в производительности.
Это не риалтаймовые задачи (в отличие от игр): вы один раз отлаживаете пайплайн, а потом каждый раз просто запускаете кодирование и уходите пить пиво или ложитесь спать.
А зачем кодировать видео и mp3?
Странный вопрос. Я даже не знаю, что ответить, кроме «надо».
У автора данной статьи вообще довольно странная аргументация: все, что выходит за переделы его привычного usecase, — не нужно :)
Действительно странный. Наверное это надо кому, кто занимается видеомантажем? И неужели он камеру купил, а на компьютер не хватило?
И да, это действительно домашнее занятие?
>Наверное это надо кому, кто занимается видеомантажем?

Мне, например, надо сконвертировать музыку перед записью на usb-flash, потому что аудиосистема в машине не понимает flac.
Видео в том числе с камеры. Иногда качаю мультики детям, а dvd-плеер понимает не все форматы.

>И неужели он камеру купил, а на компьютер не хватило?

Хватило, именно на компе я этим и занимаюсь. А где ещё?

>И да, это действительно домашнее занятие?

А мне надо на работу нести всё это барахло, чтобы перекодировать?
Вполне обычный и домашний таск — привезти видео и фотки из путешествия и обработать/сконвертировать.
НЛО прилетело и опубликовало эту надпись здесь
Скорее всего памяти мало. В 8 летний ноутбук все же легко поставить 4 ГБ :)
P.S. i5-2500 eclipse просто летает.
Далеко не во все 8-летние; например, в мою версу (март 2006 г.) влезает максимум два (чипсет больше не умеет).
НЛО прилетело и опубликовало эту надпись здесь
1. Купите SSD, если у вас его еще нет

Очень специфичная для Linux информация, ведь для Windows или Mac OS он бесполезен… Да?

любой, даже самый дешевый SSD, сократит время запуска большинства программ до 0

Увы, ложь. Игры, весящие по 10+ ГБ и загружающиеся с HDD примерно за 30-40 секунд, за 0 секунд с SSD не загрузятся. Напомню, в названии звучало «для desktop и игр».

3. Используйте 64-битное ядро

Опять же, очень специфичная для Linux информация, для WIndows она полезна не будет.

По остальным пунктам я надеюсь услышать комментарии профессионалов, т.к. если в указанных мною информация подана, скажем так, немного предвзято, не факт, что в остальных всё иначе. Просто я помню, как «спецы» долго доказывали, что в WIndows файл подкачки вреден (на самом деле нет), вот у меня сейчас сомнения и ассоциации с теми, «супер-профи» статьями возникает.
Побалуйте себя мороженым или вообще чем то сладким и все станет не таким серым и унылым )
Исходя из личного опыта, если RAM достаточно, то выключение свопа в винде ведет к более отзывчивой работе системы.
Некоторым играм пофиг, а метро 2033 у меня стало грузится за 1-2 секунды, вместо 10+.
Про своп — миф win9x, даже в winxp я уже не замечал каких-либо изменений при его отключении (если конечно памяти достаточно)
НЛО прилетело и опубликовало эту надпись здесь
Своп не миф. Своп способ удовлетворить неограниченные запросы ПО на память при ограниченном количестве оной. Единственный вменяемый ответ на вопрос «зачем своп выключаешь?», который я слышал это «2Гб жесткого диска жалко, лучше я на эти гигабайты файлов запишу». Других аргументов нет. Тут вопрос лишь в том, что система сделает в редком случае нехватки оперативки: грохнется, прибьет случайный процесс или скинет неиспользуемую страничку на диск. Если жалко места на жестком диске, то возможно стоит смириться с редкими падениями системы от нехватки памяти. Вы мапинг файлов в память тоже злом считаете? Как боретесь? А ведь эта процедура происходит гораздо чаще чем свапинг и должна давать большую просадку в производительности.

Вот вам пример как свапинг используется у меня: 4Gb оперативки; компеляется что-то очень большое в tmpfs, и тут мне приспичило запустить пару-тройку виртуалок; то что было в tmpfs спокойно переместилось на диск, в своп… компиляция пошла чуть медленнее, но виртуалки работают вполне себе комфортно. В случае отказа от свопа, кому-то бы пришлось умереть. Наверное стоит докупить памяти, и я куплю, но завтра…

И кстати вы не упомянули про tmpfs. Вы считаете целесообразным использовать половину оперативной памяти для нее в случае отказа от свопа? Не слишком дорого?
еще у меня лично была ситуация, причем аж на win7x64, что без свопа драйвер от 3G модема Ericsson периодически выдавал голубой экран. что-то там у бешеных шведов с квалькомом было криво сделано.
Да многие программы отказываются стартовать, если своп отключен. Если я не ошибаюсь, Civilization 5 тоже таким страдает. Помогает установить своп минимального размера, например 100 мб.
если бы стартовать, нет, тут при длительной работе сначала умудрялся подвисать сетевой интерфейс модема, а при попытке рестартовать его и работающий поверх openvpn — БАБАХ и голубой экран.
12 ГБ памяти на моем компьютере, oom-killer никогда не срабатывал еще, не понимаю о каких проблемах вы говорите.
На мой взгляд компьютер, который постоянно свопится — дико тормозит и так работать нельзя.
Кстати, да… vm.swappiness=0 в sysctl.conf для десктопа никто не отменял. Я, правда, всегда 10 ставлю, но своп все равно используется только когда он реально нужен. Так что нет смысла его отключать совсем.
А чем filemapping то не угодил?
Он, в отличие от свопа, непрозначен (в смысле, если его не юзаешь, он и не используется).
И так-то он все же ускоряет работу с файлами.
Потому что если мне нужно поработать с файлом из программы — в классике я прочитываю его весь или кусочек в память (при этом ОС его еще возможно захочет буферизовать). Получается io с диска в файловый буфер, потом копирование оттуда в хранилище, с которым работает мой код. А с мэппингом я ничего заранее не считываю; просто обращаюсь к блобу напрямую. Чтение и буферизация ОС при этом остаются, но вот последующее копирование полностью устраняется.
Мне всем угодил. Но это тот же свапинг, но без записи. Если ядру будет нужна страница памяти, то оно без зазрения совести выбросит кусок файла из памяти, а при обращении к нему, прочитает вновь, с диска. В каком месте непрозрачно? Кто мне даст 100% гарантию что смапленый файл действительно в памяти, а не на диске?

Я сий пример привел к тому, что мапинг и свапинг и многие другие штуки часть архитектуры подсистемы памяти. И памяти подсистема не станет эффективней, если просто так взять и выкинуть ее часть. Ядро свопится умеет и хочет, просто автор предлагает забрать у него куда свопится. Возможно автору стоило копнуть в сторону CONFIG_SWAP, а может есть такие как он, кто выпилил всякое упоминание свапа из ядерной подсистемы управления памятью… повторюсь суть в том, что автор не предлагает отбить у ядра желание свопися, но лишить его этой возможности. Как по мне, так это детская психологическая травма, причиненная 95 виндой, тормознуто шуршащей винтом в самом интересном месте игры. Как говорят обжегшись на молоке…

И главное автор не приводит конкретных, воспроизводимых примеров: вот своп включен, делаем то-то и то-то — отзывчивость интерфейса падает. Выключаем своп — все летает, и главное — ничего поломатым не сделалось. А не показывает, потому что такого примера нет. А если будет, то надо писать багрепорт, а не статью на хабр.
К примеру, у меня своп практически не используется на Ubuntu 12.04 LTS 32 bit (2 ГБ ОЗУ), хотя и выделен в размере 2 ГБ. На том же нетбуке, примерно в тех же юзкейсах, но на Windows 8.1, во время работы браузера (особенно эпично с IE11) своп работает нон-стоп, превращая систему в овощ из-за медленного жесткого и создавая на нем очереди на чтение и запись больше 10 000 мс.
Более того, если внезапно открыть первую из 10+ вкладок в IE, находясь на последней, будет заметно, что система грузит страничку из свопа — слышно по хрусту ЖД и видно по счетчикам производительности (присутствующей активности диска под 99% и отсутствующей сетевого интерфейса).
Впрочем, на взрослом ПК с 8 ГБ ОЗУ файл подкачки у винды оставлен чисто для галочки в небольшом объеме — для тех игр и приложений, которые требуют его наличия.
В Windows XP была какая-то проблема из-за отключенного свопа. Что-то переставало работать, что-то совершенно не связанное с памятью, сном и тому подобным. Кажется что-то связанное с работой MS-DOS приложений. Хотя точно не помню, но проблема была — это точно.
НЛО прилетело и опубликовало эту надпись здесь
От производительности оперативной памяти мало что зависит, от нее не увеличится FPS в играх

Увеличится, если используется встроенный видеоадаптер. У меня на AMD APU при переходе 1333 -> 1866 было увеличение FPS в Portal 2 с 40 до 60, что очень заметно.
Встроенная — экстрим :)
Хотя, конечно, замечание верное.
Выносить /home в отдельный раздел НАДО, потому что в случае переустановки системы можно будет с чистой совестью форматнуть корень и не протерять настройки софта даже при переходе на совершенно другой дистр.
НЛО прилетело и опубликовало эту надпись здесь
и зачем загаживать фс старыми ненужными файлами?
НЛО прилетело и опубликовало эту надпись здесь
Пойду следом за автором статьи. Он предложил купить столько оперативки, чтобы своп никогда не понадобился, а я предложу вам купить жесткий диск таких размеров, чтобы 100 гигабайт, раз и навсегда зарезервированные для системы, были на нем незаметны. И никакие файлы гонять вам не захочется :)
Для этого отлично подходит LVM. Нет места в lv — добавляешь еще из vg.
И заодно разные операции вроде «добавить еще винт» или «старый стал сыпаться; нужно срочно перенести все на новый» становятся на удивление простыми.
в /home 99% программ хранит свои данные и постоянно к ним обращается, поэтому /home должен быть на SSD.


плюс еще не всегда старые настройки корректно подхватываются другими версиями.
Использую Gentoo и Calculate уже как года 4. Обновляюсь регулярно. Единственное что на моей памяти не подхватило ошметки старых версий в /home это Skype 4.3, но и это из-за проблем с историей а не настройками, что удалось починить.
Как чинил
По ссылке способ починить историю с помощью sqlite3.

Все остальное требует изменений глобальных конфигураций.
даже при переходе на совершенно другой дистр

А вот и нет. В разных дистрах разные версии окружения. Такой переход у меня удавался только в рамках одного дистра (причем более старую версию поставить не выйдет), в остальных же случаях вылезают глюки, которые словами трудно описать. Иногда их даже сразу не заметишь.
Полностью поддерживаю. Только оперу раньше переносил, но сегодня хром сам все восстанавливает из облака.
Годами устанавливаю новую федору, не затирая отдельный /home раздел. Проблемы возникают ОЧЕНЬ редко (даже не вспомню какие были) и решаются очисткой каталога ~/.имя_программы, если что-то пошло не так при запуске. При этом от КДЕ до thunderbird у меня все настройки сохранены и не требуют вместо работы тратить часы на перенастройку всего софта.
В рамках Fedora — разумеется, я и сам так делал. Но я отвечал человеку, который сказал, что можно таким образом и дистр поменять — на Debian, например. На самом деле нельзя :)
Кстати, а почему не обновляете Fedora вручную? Я, кажется, с F16 Beta до самой F19 обновлялся постепенно — проблема была только один раз, когда во время обновления отключили электричество и под удар попали как раз yum и еще что-то важное. Так вот, с помощью ЛОРа и гугла даже это смог разрулить за полчаса. Зато это чувство установленной неизвестно когда системы, которая прошла через огонь и воду — очень хорошее чувство :)
Хм… А mint, ubuntu, debian и LMDE — это один дистрибутив или разные? :) На мой взгляд, debian-based еще не значит одинаковые. Однако переезды в различных направлениях проблем не вызывали вообще… А данные в /home я не видел, во всяком случае от приличных программ, только настройки, которые замечательно кеширует ОС после первого обращения.
80% используемого мной софта без проблем подхватывали свои настройки при смене дистра
90%. А то и больше.
Делайте бэкапы.
Вопрос к ТС — разве TuxOnIce перестал требовать SWAP для счастья? В свое время у меня создалось впечатление, что он как раз на SWAP-раздел и сохранял состояние памяти.
Не знаю, я не пользуюсь всеми видами suspend'а
Ему необязательно нужен своп раздел, помимо раздела можно использовать своп-файл или суспенд-файл, непринципиально.
TuxOnIce умеет сохраняться в файл. Кстати: если вы включите swap и будете использовать для сохранения его, то у вас будут три проблемы: во‐первых, если оперативка занята и swap тоже, то никакого suspend не будет (я всегда решал эту проблему самым простым способом — увеличением либо оперативки, чтобы swap можно было включать непосредственно перед suspend, либо swap’а). Во‐вторых, TuxOnIce вытесняет в swap всё, что может, как будто у вас закончилась оперативная память — в итоге система загрузится довольно быстро, но будет очень сильно тормозить, поскольку все страницы в swap’е. А swapoff работает явно не со скоростью чтения с диска. В‐третьих, TuxOnIce вроде имеет привычку сохранять кэши, которые вам из‐за второй проблемы совершенно ни к чему: я не смотрел, действительно ли это так, но echo 1 > /proc/sys/vm/drop_caches могло «починить» нехватку памяти.

Не знаю, что из этого отностится к suspend’у в файл.
Выносить отдельно надо как минимум /home и /var. Я вообще LVM использую. 100-200Mb под /boot, остальное место под physical volume, которое уже нарезаю средствами LVM, оставляя в группе томов как можно больше свободного места. LVM можно ресайзить, ext3/4 тоже умеет online resize, так что дальнейшее увеличение логических томов — не проблема.
200 МБ под /boot = постоянная нехватка места там при пересборке initrd.
/ на ssd ресайзю, как вы и говорите, вверх без проблем при покупке нового, смысл заниматься всем, что вы описали? какие преимущества? за 10 лет от этого были одни проблемы то с нехваткой места, то с переносом, то пятое то десятое.
Смысл отдельных разделов под каталоги — в возможности выбрать разные ФС (и по-разному их настроить), которые будут лучше решать поставленные задачи.
А что для десктопа лучше ext4? Пробовал рейзер, пробовал xfs, толку не увидел.
У меня reiser4 со сжатием для /usr/portage и для /var немного подкрученная.
Хорошо, но какая польза? Я вообще слышал что рейзер для ssd не очень подходит.
Какая польза от сжатия или шифрования данных? Ну я даже не знаю, что ответить :)
Насчет непригодности reiser4 на ssd ничего не слышал, к сожалению. Но в планах опробовать на личном опыте.
Дома мне шифровать нечего, а жать уже сжатое (медиаконтент, дистрибутивы итп) — это работа в минус.
Но в планах опробовать на личном опыте.
наверное, у меня просто за 10 лет прошел период «хочется все опробовать». и рейзер у меня стоял, и xfs, чего только не было, и тесты я разные им делал
а жать уже сжатое (медиаконтент, дистрибутивы итп) — это работа в минус.
Так как раз потому, что есть разные разделы под разные каталоги, можно на чем-то (/var, /portage, /) включить сжатие, а начем-то (/usr) — не включать, потому что нет смысла. И так же с шифрованием, и с размером блоков, и прочим.
Дома мне шифровать нечего
Надеюсь, мы не говорим о вашем конкретном случае, а об общем. Я же не пишу, что у меня ноутбук, и что мне нужен suspend to disk и потому он нужен всем. Потому что не нужен. Так и с разделами: кому-то надо, кому-то — нет.
А зачем шифровать /usr/portage?
Чтобы никто не украл секретные ебилды.
Естественно, не за чем. Это был просто пример: как отдельный раздел можно вынести и пожать. Шифровать можно / или /home.
А ещё portage можно на squashfs держать (https://github.com/init6/init_6/wiki/squashed-portage-tree)
Ага. И корень. И всего этого разнообразного великолепия мы одномоментно лишаемся, забацав все на один раздел.
Впрочем, имхо, со squashfs решение слишком уж замороченное по сравнению с прозрачным сжатием reiser4, хоть, возможно, и с некторой меньшей эффективностью сжатия.
А можно в конкретных цифрах и юзкейсах рассказать, чем ext* лучше xfs? А то даже RH, которая упиралась с ext* до последнего, в итоге признала очевидное и теперь в RHEL7 по умолчанию xfs.
# du -hs /boot
16M /boot
# ls -l /boot
итого 8555
drwxr-xr-x 6 root root 1024 авг 1 21:56 grub
lrwxrwxrwx 1 root root 41 авг 1 21:52 initramfs -> initramfs-genkernel-x86_64-3.14.14-gentoo
-rw-r--r-- 1 root root 3557172 авг 1 21:52 initramfs-genkernel-x86_64-3.14.14-gentoo
lrwxrwxrwx 1 root root 38 авг 1 21:44 kernel -> kernel-genkernel-x86_64-3.14.14-gentoo
-rw-r--r-- 1 root root 3245808 авг 1 21:44 kernel-genkernel-x86_64-3.14.14-gentoo
drwx------ 2 root root 12288 май 24 2008 lost+found
lrwxrwxrwx 1 root root 42 авг 1 21:44 System.map -> System.map-genkernel-x86_64-3.14.14-gentoo
-rw-r--r-- 1 root root 1904432 авг 1 21:44 System.map-genkernel-x86_64-3.14.14-gentoo

Не вижу проблем. При моём use case ещё ни разу не было, чтобы не хватало 100Мб. Это на Gentoo. На CentOS делаю 200Мб. И использование LVM — это не единственный повод делать отдельный boot. Это ещё и возможность запустить ядро, initramfs и shell при упавшей корневой ФС. Что до LVM — так это просто очень удобный инструмент работы с данными на диске. Больше нет проблем с экспериментами с другими ФС. А переезд на новый винт делается при работающей системе. Я уж не говорю про снэпшоты.
«у меня работает, значит у всех так» — отличный аргумент!
Зачем эксперименты с другими фс, если есть ext4? Я уже наэкспериментировался, дико жаль потраченное время, особенно на XFS.
А переезд на новый винт делается при работающей системе.

Ага, спасибо и железа я тоже много сжег работающего.
>«у меня работает, значит у всех так» — отличный аргумент!

Где я писал про всех? Надо свою голову иметь.

>Зачем эксперименты с другими фс, если есть ext4? Я уже наэкспериментировался, дико жаль потраченное время, особенно на XFS.

А ещё есть куча других ФС, и их иногда бывает интересно посмотреть. А ещё я могу сделать снэпшот перед тем, как, например, делать какие-то фатальные изменения. А ещё я могу делать бекап со снимка, что гарантирует неизменность файлов в процессе бекапа.

>Ага, спасибо и железа я тоже много сжег работающего.

А это здесь при чём? Если оборудование не поддерживает hot swap, я не предлагаю втыкать на горячую. Можно выключить комп, воткнуть диск, включить, загрузить ОС, запустить перемещение и продолжать спокойно работать, пока идёт процесс. Даже если вырубится питание, ничего страшного не произойдёт. Процесс возобновится при следующем старте.
С LVM нарвался однажды прямо на хрестоматийные грабли!
Решил увеличить /boot, на ноутбуке жены, покуда надоело раз в месяц запускать apt-get autoremove и удалять старые ядра (сама она не хочет этим заниматься, а мне хотелось сделать это вмешательство гораздо более редким).
А винт как раз размечен — раздел EFI, boot и единый большой pv. И вот тут как раз возникла проблема ресайза pv. Вроде просто — добавить еще один pv в группу, буксануть на него данные и потом лепить из освобожденного все, что угодно.
А не тут-то было! Данных достаточно много (около 200 гиг) Из доступных внешних дисков только небольшие флешки да старый медиаплейер на usb 2.0.
По итогу пригодилось, что домашний роутер — с гигабитными портами. Создал на десктопе nfs-шару, в нее положил 200-гиговый пустой файл, на ноуте подключился к шаре, подключил файл на lo-устройство, создал в нем pv, включил в группу, буксанул данные… и тут ноут внезапно завис…
Вроде lvm перемещает тома достаточно безопасно (создает новый lvm том и копирует в него экстенты, и только после успешного завершения переназначает их на старый), но тут проблема в том, что этот новый том, смонтированный из образа через сетевую шару — часть vg. И при перезагрузке он, естественно, не был найден initrd (откуда ж ему знать, что нужно лезть в nfs и смотреть вон-в-тот файл).
Благо, на том же роутере помимо гигабитных портов воткнут винт, и поднят сервер для сетевой загрузки той же убунты. Грузился в него, там заново собирал всю vg и завершал перемещение. Все получилось, но осадочек все равно остался.

Правило, которое я для себя усвоил — если хочется отдать один огромный раздел под pv для lvm, то лучше его разбить на несколько, и добавить эти несколько pv. На скорость работы это никак ощутимо не повлияет, зато в случае необходимости останется маневр для манипулирования этими pv в пределах диска.
lvm всегда можно запустить без недостающего pv, а сама утилита lvm при каждом изменении конфигурации создаёт бекап метаданных. Я восстанавливал данные даже с частично затёртых pv. PV с затёртыми метаданными, конечно, нельзя использовать внутри группы, но эти метаданные можно восстановить из бекапа. Так же и с отвалившимся во время перемещения pv. Можно было восстановить метаданные группы на момент до перемещения.
Genkernel не пересобирает initramfs в /boot. Так что не =, во всяком случае, не у всех. Лучше пните того, кто писал программу для сборки initrd в вашем дистрибутиве.

И не надо пинать Black_Shadow: «у меня не работает, значит у всех так» — это тоже неверное утверждение. Он указал, при каких условиях у него работает. А вы не указали, при каких условиях у вас нет.
Genkernel не пересобирает initramfs в /boot.

Вообще-то собирает:
andreilPC / # ls -l /boot
total 11420
drwxr-xr-x 6 root root 4096 июл 9 16:53 grub
-rw-r--r-- 1 root root 2136589 авг 15 08:17 initramfs-genkernel-x86_64-3.15.0-gentoo-r1
-rw-r--r-- 1 root root 5963936 авг 15 08:17 kernel-genkernel-x86_64-3.15.0-gentoo-r1
-rw-r--r-- 1 root root 3559631 авг 15 08:17 System.map-genkernel-x86_64-3.15.0-gentoo-r1
Я сказал не собирает. Никто не сомневается, что результат сборки находится в /boot.
Извиняюсь, не так понял суть предложения :)
Зачем мне его пинать, я больше не занимаюсь бредом в виде вынесения /boot в отдельный раздел и соответственно таких проблем не имею. А дистр, где такой скрипт — убунта.
Не надо называть отдельный /boot бредом. Вам уже привели несколько причин, зачем это нужно. Если к вам эти причины не относятся или вам кажется, что они к вам не относятся, то это не значит, что отдельный /boot является бредом. Я его тоже не везде ставлю отдельным.

Genkernel, кстати, позволяет настраивать место, где будет происходить сборка, по‐умолчанию использует /var/tmp. Ничего подобного в документации к initramfs.conf я не нашёл.
GRUB2 умеет обращаться к /boot, расположенному на LVM. Так что можно не выносить вне PV.
Да, на чтение, но мне как-то нужна была запись (grub сохранял переменные). Теперь уже не надо, но /boot так и остался отдельным разделом, а не логическим томом.
А объясните пожалуйста, в чем принципиальный смысл отдельного раздела под /boot? Для /home и прочих /media понимаю и сам пользуюсь (корень на SSD), но к чему отделять на десктопе /boot от корня — так и не уловил.
Мне кажется, что при упавшей корневой ФС запуск ядра и shell будет наименьшей из моих проблем :) Опять же, LiveCD и прочие сторонние источники загрузки всегда есть под рукой, так что решаемая таким образом задача видится мне довольно надуманной.
не всегда бывает так что
LiveCD и прочие сторонние источники загрузки всегда есть под рукой

так что не уверен что задача настолько надуманна. Гораздо проще загрузится без «сторонних источников».

PS: IMHO
(осторожно) а что, CD-дисками до сих пор пользуются?
Сомневаюсь… Сам постоянно таскаю с собой флешку с SysrecueCD (Live-версия Gentoo).
У меня Zalman VE-300 как эмулятор всего-всего
Ну, эмулятор это всё же не совсем диск. Просто .iso исторически стал на pc диском-контейнером, на котором можно дежать самодостаточную систему. Примерно как .dmg на маке.
А вот именно сам диск, кругленький такой :) Да на современном железе?
А зачем нужны диски-то?
Ну вот тут выше написали, что grub2 уже умеет доставать данные с lvm, поэтому сейчас может и незачем. А так-то смысл был. Как раз ради успешной загрузки.
А кроме grub2 есть и другие варианты. У меня, к примеру, /boot отформатирован в hfsplus и grub положен прямо на него. А вся система живет в lvm, с которым ядро начинает общаться, получив нужные модули и софт в initrd. И «вся эта хрень» нужна для того, чтобы стандартный маковский загрузчик смог увидеть этот раздел и включить его в загрузочное меню. Иначе до grub вообще дело не доходит!
Так-то да.
Но на той же убунте /boot разумнее сделать где-то с 1 гиг.
Иначе два-три апдейта ядра — и уже «ой, что-то загрузиться не может»
К счастью, я не пользуюсь убунтой
>как уже было сказано проблемы износа SSD нет, это миф, и большое число циклов записи вообще не влияет на долговечность SSD

Лютый бред. Какой нафиг миф? Ограничение ресурса на количество записей есть, оно обусловлено технологией. Другой вопрос, что его хватит на несколько лет. А некоторым пользователям возможно и лет на 20. Но сам износ есть, глупо его отрицать. Ну и ни слова о том, что порядка 99% SSD дохнут от внезапной смерти контроллера, а не от износа.

Дальше не читал. Ибо будет такая же чушь.
99% SSD дохнут от внезапной смерти контроллера

ага. sandforce 2009 года.

Другой вопрос, что его хватит на несколько лет.

действительно, мне ОЧЕНЬ важно, хватит моего ssd на 20 или на 30 лет работы. типичный юзер выбрасывает диски после 5 лет.
Эх, похоже я атипичный юзер — у меня хранятся диски 12 летней давности. Правда, на материнке уже нет интерфейсов куда их подключать… :)
Класс, у меня тоже хранится диск с первого компьютера. В коробке, правда.
В телефоне места больше, чем там.
>ага. sandforce 2009 года.
Любые дохнут.

>действительно, мне ОЧЕНЬ важно, хватит моего ssd на 20 или на 30 лет работы. типичный юзер выбрасывает диски после 5 лет.
Никого не волнует что вам лично важно. А вот обманывать людей, рассказывая всякую чушь, нехорошо.
Любые дохнут.
Тогда пришло время одевать шапочку из фольги.
А вот обманывать людей, рассказывая всякую чушь, нехорошо.
Ох извините, не 20, а 19 лет, ну может 15, а может и 16. Серьезная ошибка!
Простите, я не специалист, но всё же…

Насколько я понимаю, если умирает контроллер на жестком диске, его можно заменить. Это — только за отдельные деньги и нужен специалист, но в моем городе есть контора, которая честно кушает хлеб с икрой, выполняя эту работу.

А если умирает контроллер на SSD (вы же не будете отрицать, что это может случиться с любым, даже современным диском), что тогда? Починят, или только выкинуть?

Просто, все мы грешны, и не всегда и не всё бэкапим. Особенно, на домашних компьютерах. Увы…
В данном случае поможет только шапочка из фольги. Я серьезно.
Мда… это уже клиника… из-за того что электроника дохнет, надевать шапочку?

>Ох извините, не 20, а 19 лет, ну может 15, а может и 16. Серьезная ошибка!
Только вот в статье то написали, что ограничение ресурса это вообще миф. Что есть брехня. А теперь на попятную? Вам бы в чиновники с таким подходом. Будете среди братьев по разуму)
Ну вот, тем, кому не хватает 15 лет ресурса жестких дисков надо садить за 10 гиговые диски 1999го, чтобы не несли свою брехню дальше.
В 1999 еще ССД не изобрели, кстати, так что проблем с их надежностью вообще не будет!
Ну т.е. теперь ограничение ресурса уже не миф? Уже 15 лет даже, а не 30?
Вы уж определитесь как нибудь, а то народ над вами потешается))
Пока я вижу только одного жирного тролля, которому вот сейчас отвечаю.
Буквально в том месяце ходил менял сдохший SSD. Гарантия на него три года, так что в целом пофиг. И да у меня там была только система, никакого /home. А вот в случае ваших советов я бы еще /home потерял.
Ужас! А если бы сдох винт на котором /home кто был бы виноват?
Правильный ответ: тот, кто не делает бэкапы.
Ужас! А если бы сдох винт на котором /home кто был бы виноват?

У меня /home RAID1 это так к слову. И все оттуда нужное забекаплено. Но это же поднимать потом надо будет. Так что я лучше пешком постою. Без /home на ssd
Вообще-то вам всё правильно говорят про /home на SSD. Переносить весь домашний раздел на твердотельный накопитель скорее даже вредно.

SSD лучше всего подходит для множества мелких, разрозненных файлов, которые чаще читаются, чем пишутся. Поэтому, например, SSD так популярны в качестве системных — всё грузится и запускается очень быстро. По этой же причине очень удобно держать на SSD исходники, дерево портов FreeBSD и другие подобные ассеты: нулевой seek time значительно ускоряет сборку и поиск по куче (сотни тысяч) относительно небольших файлов. Имеет смысл держать на SSD и L2ARC/ZIL кэши ZFS. Но обратите внимание: во всех случаях (кроме последнего) данные чаще всего читаются, чем пишутся, т.е. SSD не подвергается усиленному износу. Использование же SSD для кэширования ZFS хоть и превращает его в довольно дорогой расходник, но в этом случае нам вообще пофиг на его внезапную смерть (вернее, на данные) — была бы замена наготове.

По поводу того, что 99% программ хранит свои данные и постоянно к ним обращается — во-первых, это утверждение неверно: основные свои данные программы хранят где-нибудь в /usr/local/share, а в $HOME пишутся конфиги, результаты работы и пр., а во-вторых, для этого уже очень давно придумали буферизацию, кэширование и отложенную запись (мета)данных, так что смысла переносить, повторюсь, весь /home на SSD (и тем более настоятельно это советовать) нет. Исходники и всё такое — да, можно и нужно. Но их-то как раз потерять не страшно, если что — всегда можно зачекаутить заново из репозитория. Ну и бэкапы, конечно, никто не отменял.
Один браузер чего стоит в плане обращений к каталогу пользователя.
Труъ-шапочка из фольги хранит кэш браузера в tmpfs.
SSD не подвергается усиленному износу
Для того, чтобы SSD не подвергался усиленному износу есть хороший совет — после покупке храните его в закрытом, недоступлном для света и детей месте, при температуре до 25 градусов.
Про то, что диски (любые) чувствуют себя ненужными, расстраиваются и впадают в депрессию, если их не использовать, я знаю. :-)

Я о том, что можно получать реальные бенефиты от правильного использования SSD в течении, скажем, 10-15 лет, а можно просто ушатать его впустую, воткнув его без особого толку под большую нагрузку.
Ну вот у меня лежит мой 3 (или 4) летний SSD на 60 ГБ. Что с ним сейчас делать? Продать за 500 рублей жалко, а в дело пускать — некуда.
Надо бы разыграть его с условием обязательного использования в течение последующих 15 лет.
И да, после моего «варварского» использования у него еще осталось где-то 85% здоровья.
Ну, если сейчас некуда, значит пусть лежит на полочке, авось пригодится. 60 гигов — вполне можно использовать как системный, например.
Так у меня уже под систему 240 гиг, что позволило, кстати, отказаться от HDD в компьютере вообще — убрал его в NAS.
А зачем вы советуете не латать ядро? Чем ваше 3.12 лучше 3.17 (ну окромя конечно что на 3.17 pf еще нет)?
Насчет 3.17, это я конечно погорячился… скорее 3.16 (и pf кажется для него уже вышел). Вот читаю щас kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.26 и не могу понять что вам в этих патчах не нравится.
Все просто: в pf-патчсете уже есть весь набор стабилизационных патчей. Так что 3.x превращается в 3.x.latest
А точно, не (судя по Makefile) в 3.12.4? И чисто визуально, патч на kernel.org весит больше чем весь pf(700Kb против 500Kb).
Даже не знаю, вопрос к патчу…
А можно нубский вопрос: как в линуксе ставить самый свежий софт, который не появился еще в репозитории (у меня убунту и ксубунту).
Добавлять ppa или компилять из исходников.
P.S. лучше пользоваться стабильными версиями и самое-самое ставить только по крайней необходимости.
Пользуясь моментом, напомню фразу одного замечательного человека megabaks :
«Вы ещё верите в стабильность стабильной ветки?»
Как-то сидел на нестабильной, вспоминаю с ужасом. А еще пакеты обновлялись чуть ли не каждый день, а это было во времена очень дорогого интернета (тогда еще дома не безлимит был).
можно использовать не убунту. В некоторых других дистрибутивах обновление версий ПО происходит быстрее, например Gentoo или Calculate. Вы можете попробовать использовать их. Я не агитирую и не коим образом не хочу начинать холивар.
Ну это точно совет не для нуба :)
Да нет большой разницы. Если хочется свежий софт то вариант хороший. документации много. Система portage тоже не сложная. Я ж не предлагаю Slakware или Vanila :)
А я как раз в той начальной стадии когда все пробую дистрибутивы. Xubuntu очень зацепила аккуратностью интерфейса и приятной организацией работы, почти как в винде.
Почему-то ни слова не сказано про включение trim для SSD. Или современные дистры уже сами определяют SSD и монтируют с нужным параметром? На мой взгляд для SSD это важная опция.
Сказано:
В Ubuntu 14.04 SSD работают из коробки, опция discard автоматом прописывается в fstab, кроме этого больше ничего не нужно делать.
Прошу прощения. Не заметил. Но, все же есть и другие дистры. Нигде в тексте или заголовке не указано что тюнинг производится конкретно под Ubuntu 14.04. Упоминается только один раз в контексте SSD.
Ок. Добавлю
А нет, уже не добавлю, слили карму.
Что не совсем верно. Оно включено только для Samsung и Intel дисков.
Всем остальным нужно включать руками.
А нужно?
А то вот тут пишут, что вроде как не обязательно:
www.leaseweblabs.com/2013/12/ubuntu-14-04-lts-supports-trim-ssd-drives/

У меня интеловский ssd, тоже слышал, что 14.04 сама разберется с ssd, поэтому не трогал настройки. Сейчас глянул в fstab, discard не прописан.

В общем, я запутался.
Коротко: TRIM ускоряет запись, если на диске мало места.
Да не, ставил на M4 — так же прописалось.
TRIM автоматом включается уже весьма давно.
И не только TRIM. Чтобы получить максимум выгоды от перехода на SSD, может потребоваться довольно тонкая настройка системы: определить erase block size и выравнять границы разделов, выбрать наиболее подходящую файловую систему, опции newfs(8) и монтирования, etc. Вот, навскидку, несколько ссылок: раз, два, три.
При создании используйте -T largefile или largefile4.

А разделы к 4096-границам обновленные утилиты автоматом создают.
Этого может оказаться недостаточно: у многих SSD erase block size кратен мегабайту. В целом же я согласен, что современные версии утилит, инсталляторов и дистрибутивов вообще зачастую в курсе про SSD, и ручная настройка требуется не для всего и не всегда.
Можно не лишать себя возможности отправлять систему в hibernate оставив swap и выставив vm.swappiness = 0 в /etc/sysctl.conf. В этом случае swap будет использоваться только для ухода в сон.

Оставляя один раздел на диске вы обрекаете себя на кучу дополнительных действий при перестановке системы и смене дистрибутива. В любом современном дистрибутиве можно воспользоваться LVM. Помимо избавления от проблемы с ресайзом разделов приобретаются дополнительные плюшки, например, возможность добавить в существующий логический том еще один физический диск, и растянуть раздел на два диска.

Если компьютер — ноутбук или дектоп, подключенный через UPS, можно увеличить commit time для SSD, есть вероятность улучшить отзывчивость системы. Также можно попробовать выставить noop в качестве планировщика, на случай, если в контроллере диска уже есть свой, встроенный.

А вообще, если уж играться с кастомными ядрами и сторонними патчами, то можно и Gentoo поставить. Там будет и возможность включить все возможные оптимизации, и выпилить все ненужное из программ с помощью USE-флагов, и для pf-kernel там есть ебилды.
В этом случае swap будет использоваться только для ухода в сон.

Ну, нет. Система все равно будет свапится, о только в крайних случаях. Но будет. Мегабайта 2-3 будет в свопе висеть.
Недавное заметил что vm.swappiness не для всех приложений работает, работая через vagrant и виртуальную машину в какой-то момент вся память начинала сливаться в свап, полностью вся, потом когда оставалось где-то 10-20мб загружалась из свапа обратно, процесс занимал минут 15, в итоге просто убрал свап из системы так и не понял что это было.
Я вот тоже не понимаю свапофилов. Вот был старый совет — иметь 1.5-2х от размера оперативки свап. Допустим у меня 4 Гб памяти, я делаю еще свап на 8. В итоге — 12.
Потом я докупил 8 ГБ памяти. Получилось 12 ГБ физической, и что мне свап теперь не нужен? Ведь виртуальной памяти без свапа у меня так же — 12 ГБ.
Короче, толк от свапа объяснить никто не может
в целом от свапа есть толк, вернее появляется тогда когда оперативная память закончилась =), но если ее много наверное будет только хуже.
Получилось 12 ГБ физической, и что мне свап теперь не нужен? Ведь виртуальной памяти без свапа у меня так же — 12 ГБ.
Swap нужен не только в том случае, если кончается память.

Ядро Linux умеет выгружать в своп неиспользуемые страницы памяти, принадлежащие процессам, которые запущены и не используются. На освободившееся место ядро помещает различные кэши, ускоряющие работу с, например, mmapped-файлами.

С большинстве случаев это ускоряет работу компьютера.
Лично я субъективно никогда не замечал положительных эффектов от этого.
А вот когда свернутая пару часов назад программа начинает при разворачивании мучительно насиловать винт и прорисовываться по кусочкам — изрядно раздражает.
На ядрах от 3.5 и выше vm.swappiness = 0 совсем выключает swap. Тогда и смысла подключать его нет. swapoff -a даст тот же эффект.
Ставить нужно vm.swappiness = 1, чтобы не лишать себя возможности подсвапить малеха, когда прижмет.
А UKSM у вас стабильно работает? Пробовал его месяца 3 назад, при сильной нагрузке он мне вешал систему наглухо.
И по поводу SWAP, не у всех есть десятки гигабайт оперативки, в таких случаях стоит попробовать zRam, компромиссное решение между отдельным файлом/разделом и вообще отключением свопа.
У меня тоже пару раз завешивал систему своим процессом, который еще и не убьешь. Больше я его не включаю.
А BFQ действительно нужен, когда система стоит на SSD? Я не очень хорошо разбираюсь в вопросе, но читал, что для SSD это вообще не сильно актуально и можно включить NOOP, который вроде есть в ванильном ядре.
Теоретически не актуально, но практически BFQ все же самый «живучий» под нагрузкой.
Так как у меня не ноутбук, я выключаю все что связано с энергосбережением, то есть к примеру выключаю поддержку CPU Frequency scaling вообще.
А то, что комп в разы больше потребляет электричества, греется и гудит всем вентиляторами как пылесос вас не смущает вообще?
governor по-умолчанию: performance все равно, так что это ничего не меняет
Некоторые советы хорошие, некоторые откровенно вредные, вроде выключения frequency scaling. Я ожидал большего, честно говоря.
Я, вот, могу написать про тонкую настройку задержки ALSA ± PulseAudio для игры, тонкую настройку ускорения мыши (а типов ускорения в Linux аж 7 типов!), управляемый троттлинг для лаптопов.
О, это было бы полезно! Ждем статью. За критику спасибо. Наверное перестарался насчет frequency scaling
Наверное перестарался насчет frequency scaling
И ещё один момент. Принудительно включая все ядра на полную частоту, вы тем самым отключаете такие современные технологии как Intel® Turbo Boost или AMD Turbo Core, которые могут увеличивать (весьма существенно) частоту одного или нескольких ядер в те моменты, когда нужна высокая скорость, а другие ядра простаивают.

Сегодня полностью ядра не все игры могут использовать. Вернее, использовать могут не только лишь все, мало кто может это делать (по мотивам глубоко философского высказывания © Виталия Кличко)

Причём это справедливо не только для игр, но и для серверов.
Скорее всего в этом и заключается феномен снижения циферок в бенчмарке, спасибо за наводку!
Некоторые игры до сих пор в принципе не научились использовать более одного ядра. В итоге в них вся производительность обычно упирается в raw processing power одного ядра. И это печально.
Таких меньшинство. Как минимум 2 ядра из современных умеют почти все.
Пожалуйста напишите! Ну если не статью, так хоть основные моменты по ALSA ± PulseAudio.
Но используя 64-битное ядро, приложения могут адресовать больше чем 4 ГБ памяти, что довольно полезно, так как иначе может возникать ситуация когда OOM-killer будет прибивать программы, хотя оперативки еще достаточно.

Никакое 64 битное ядро не поможет вашей 32 битной программе адресовать больше 3 гиг памяти. Так что фактически выполняется только если у вас ПО так же 64 битное.

PAE кстати сильно не сказывается на производительности. Но в случае если в системе больше 4 гиг памяти действительно лучше поставить 64 битное ядро.

Насчет патчей, я уже давно живу на стандартных ядрах Fedora и ничуть от этого не страдаю. Так что с моей точки зрения все эти прыжки с ядром для десктопа с достаточным количеством памяти и приличным процессором просто лишены смысла.

Про таблицу разделов так же присоединюсь. Нужна она. Swap кстати говоря полезен. К примеру если у вас есть не используемая обширная программа, то ОС выпихнет ее в swap и для другого ПО будет доступно больше памяти. Конечно потом она будет его доставать оттуда некоторое время :)

Насчет SSD для системы, это да хорошо. Для данных далеко не всегда. В случае если у вас множественное случайное чтение, то да. В случае линейного чтения SSD, смысла уже мало брать. Так-как за те же деньги можно взять существенно более емкий HDD.

Я обычно сам себе менеджер RAM в таких ситуациях. Всегда держу количество запущенных процессов под контролем, дабы не вылезать за границы физической RAM. Поэтому для меня лично своп — адское зло. Выгружает программы, которые я на некоторое время свернул, несмотря на то, что у меня и в мыслях не было запускать еще десяток тяжелых процессов, лучше бы эта свернутая осталась в RAM.
Вы можете отучить систему агрессивно выгружать программы с помощью выставления меньшего swappiness. Подберите подходящее для вас значение и оставьте роль менеджера RAM операционной системе.
Да, обычно именно так и поступаю, во избежания падений по нехватке памяти.
Однако, если доращу наконец себе физическую RAM до 16 Гб — выключу своп вообще.
Итак, отключая swap вы:
— создаете условия, для потенциального падения приложения во вполне стабильной ситуации, когда приложение не рассчитано на работу без свопа
— вы создаете риск падения процессов по недостатку памяти
— впридачу вы усложняете процесс дефрагментации памяти менеджеру памяти, а значит
* вы замедляете процесс выделения памяти
* создаете риск для процесса вывалиться по нехватке памяти даже тогда, когда ее формально достаточно
— плюс черт его знает как в таких условиях поведет себя дисковый кэш

все падения процессов по нехватке памяти — это потеряные данные, а может даже попорченая файловая система.

и ради чего это все? ради того чтобы редкоиспользуемые приложения быстрее возвращались в активное состояние.
Всех перечисленных ситуаций я ни разу не встречал при работе с отключенным свопом.
А приложения имеются ввиду не редкоиспользуемые, а просто временно свернутые по какой-либо причине.
Плюсую. И у меня вышеперечисленного никогда не было.
Почему тогда на VPS нет свопа?
Скорее всего потому что вы или ваш хостер его не включили. И вообще VPS бывают разные. Вы о каких?
НЛО прилетело и опубликовало эту надпись здесь
Я вот тут подумал — UKSM предназначен для уменьшения потребления памяти, и скорее, вносит непредсказуемые скачки нагрузки… Так что если мы говорим про плавность и стабильность интерфейса — UKSM не нужен, и заменяется докупленной оперативкой.
Того же мнения. Благо он по-умолчанию выключен.
Разве? Я, помнится, в сорцах ковырялся около года назад, и оно было включено в режиме «full» из коробки. Для самосборного ядра после патча uksm я применял свой, который выставлял режим «quiet». По большей части, UKSM такой уж прям экономии (хотя бы 1%) не даст, поверьте на слово.
Да, экономии никакой :(
Я то думал, раз я одинаковые игры запускаю в двойном экземпляре — будет толк, но его ВНЕЗАПНО нет, при этом оно пару раз завешивалось, так что kill — 9 не помогал.
Но то что выключено — это точно:
KSM is inactive until a program has madvised that an area is MADV_MERGEABLE, and root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set).
Стоп. Это «стоковый» KSM, а тут ведь речь про UKSM, которому (емнип) сей закон не писан.
Там опция есть, чтобы выбрать каким KSM'ом пользоваться, но включаются они одинаково через /sys/kernel/mm/ksm/run, просто UKSM работает для любых программ, не только у которых флаг MADV_MERGEABLE
Также, использование 64 ядра не требуется для адресации более 4 ГБ памяти, PAE позволяет адресовать до 64 ГБ памяти на 32 битной системе.

Но используя 64-битное ядро, приложения могут адресовать больше чем 4 ГБ памяти, что довольно полезно
Я не очень понял вот эту фразу, не могли бы вы пояснить, что все-таки имелось в виду?
32-битное ядро может использовать до 64 ГБ физической памяти, но на процесс будет все равно ограничение в 4 ГБ.
НЛО прилетело и опубликовало эту надпись здесь
Ничего странного.
Автор не разбирается в теме вообще. Он прочитал бложик какого-то товарища и решил, что теперь он познал истину.
Результат мы видим тут.
Это мой бложик.
Это Хабр.
Автор говорит про некий бложик, так вот у меня есть свой бложик, где я выкладывал раньше эту статью, но немного недоделанную.
prelink и правда забыл вообще. очень действенная штука.

Не хватает сравнительных тестов.
Прокрутите в конец. Правда я там сам себя затраллил.

Хотелось бы поинтересоваться, какие десктопные линуксовые приложения могут занимать больше чем 4 Гб памяти, и насколько часто они используются?
В играх легко упирается. Dota 2 ярчайший пример.
Почему бы вам не написать статью? Я серьезно.
НЛО прилетело и опубликовало эту надпись здесь
Я им пользуюсь уже четыре года, но про половину перечисленных «правил хорошего тона» не слышал. Но мое дело лишь предложить было.
Хотелось бы поинтересоваться, какие десктопные линуксовые приложения могут занимать больше чем 4 Гб памяти, и насколько часто они используются?
Практически любое мультимедийное приложение, работающее с большими файлами, например граф. редакторы, кады, рендеры (парочка PNG-текстур весом мегабайт 50, а это вполне нормально, и привет), raw-конвертеры.

Те же самые приложения, что и под любую другую ось, кстати. Linux тут не при чем, дело в обрабатываемых данных.
НЛО прилетело и опубликовало эту надпись здесь
Вывод — 1000Гц.
И эти люди запрещали мне ковыряться в носу…

Файл linux/kernel/Kconfig.hz гласит:
choice
        prompt "Timer frequency"
        default HZ_250
        help
         Allows the configuration of the timer frequency. It is customary
         to have the timer interrupt run at 1000 Hz but 100 Hz may be more
         beneficial for servers and NUMA systems that do not need to have
         a fast response for user interaction and that may experience bus
         contention and cacheline bounces as a result of timer interrupts.
         Note that the timer interrupt occurs on each processor in an SMP
         environment leading to NR_CPUS * HZ number of timer interrupts
         per second.

        config HZ_100
                bool "100 HZ"
        help
          100 Hz is a typical choice for servers, SMP and NUMA systems
          with lots of processors that may show reduced performance if
          too many timer interrupts are occurring.

        config HZ_250
                bool "250 HZ"
        help
         250 Hz is a good compromise choice allowing server performance
         while also showing good interactive responsiveness even
         on SMP and NUMA systems. If you are going to be using NTSC video
         or multimedia, selected 300Hz instead.

        config HZ_300
                bool "300 HZ"
        help
         300 Hz is a good compromise choice allowing server performance
         while also showing good interactive responsiveness even
         on SMP and NUMA systems and exactly dividing by both PAL and
         NTSC frame rates for video and multimedia work.

        config HZ_1000
                bool "1000 HZ"
        help
         1000 Hz is the preferred choice for desktop systems and other
         systems requiring fast interactive responses to events.

endchoice

Думаем, размышляем, много размышляем (желательно, по количеству ядер в целевом ПК), попутно вспоминая про 12309 (немифический и не в вакууме).

Вывод: Ваши 1 КГц хороши исключительно на Вашем же Pentium 4, а мой скромный Core 2 Quad они будут зазря передёргивать.

PS: а ещё можно поиграться с kernel preemption для достижения цели, ага.
НЛО прилетело и опубликовало эту надпись здесь
Увы, но процессорами старше 10 лет пользоваться это грех.
А так да, в те времена я врубал 1000 HZ и Preemptible kernel. Тогда еще и big kernel lock существовало.
Genkernel мне с какой‐то радости поставил 100 Гц. Наверное, это надо считать умолчанием для Gentoo.
SSD нет, vanilla kernel, всё летает, ЧЯДНТ?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А что если я загружаю систему в среднем раз в месяц? У меня linux не грузится, а работает быстро.
НЛО прилетело и опубликовало эту надпись здесь
Из всех советов пожалуй полезными являются только переход на SSD (спасибо кэп) и хранение /home на нем же.

А далее честное признание в конце статьи в том, что в результате шаманств тесты стали показывать хуже результат.

32bit ядро, если не ошибаюсь и 32bit процессы на 32bit ядре будут чаще работать в пределах кэша процессора, а значит производительность будет повыше. 64 бита нужно, если знаем, что наши процессы съедают более 2-4гб каждый. Опять же на диске 32 битная система занимает меньше места (не надо держать копию 32 битного рантайма)

Выключение свопа — уже много кто отписался. Черевато проблемами и не понятно ради чего.

все на одном разделе — это пока жареный петух не клюнет. В /home и /var мы пишем часто, а значит шанс грохнуть fs увеличиваем, а вот если / сделать RO при монтировании, то даже при умершем /home /var можно загрузиться и попробовать что-нибудь востановить. Опять же можно проставить разные флаги в зависимости от использования каждой партиции, опять же можно врубить write caching когда знаешь, что ничего ценного этим не повредишь.

Не хватает места на SSD? Купите второй — 128Gb сейчас стоит в районе $50, 256 в районе $100. А память, кстати, подорожала.
Тесты показали минус скорее всего из-за выключения Turbo boost, думаю, сегодня удастся перепроверить.
Насчет SWAP-раздела: он вам не нужен. Если у вас не хватает оперативной памяти, то OOM-killer будет прибивать ресурсоемкие приложения, если это происходит то докупите оперативки, благо ее цена не сильно кусается.


Еще одна сказка. Я тоже когда-то в нее верил, собрав десктоп-сборочную станцию о 32 гигабайта оперативки. Проблема в том, то при запущенной мултипоточной сборке (у меня шестиядерник с HT) на tmpfs в 15 гигабайт OOM-killer все равно сносит некоторые процессы, хотя по всем мониторингам оставалось более 5 гигов памяти свободно. Толи он не успевает очистить кеши какие-то, то ли еще что, мне досконально докопаться до этого не хватает скилла.

Но своп нужен. Можно небольшой. Можно со swappiness = 0. Но не хотите в определенный момент времени отлавливать совершенно непонятные проблемы — не отключайте его. Своп на VPS не включают хостеры либо слишком жадные, либо слишком ленивые. Я с такими борюсь либо рублем, либо своппингом в файл.
А посоветуйте тогда какой-нить запасной своп для свопа? Вдруг у меня не хватит и оперативки и свопа, и oom-killer разбушуется? А потом понадобится своп для запасного свопа и так для бесконечности.
Проблема недостатка памяти решается увеличением памяти, а не костылями.
Прежде, чем умничать, почитайте как линукс работает с памятью. И еще желательно прочитать коммент, на который Вы отвечаете. Бывают такие ситуации в линуксе, когда память еще есть, но система хочет что-то кинуть в своп. И если не кинет, то включает оом-киллер.

И если Вы никогда с ними не встречались и недостаточно хорошо понимаете как работает ОС, про которую Вы пишете, это не значит, что всем стоит так делать.

В любом случае я не вижу проблемы, создать своп на пару гигов и указать swappiness = 0. И своп будет и использоваться он почти не будет кроме крайних случаев, если памяти хватает.
Вы одно понять не можете: swap — это запасная память. Когда он начинает использоваться — компьютер начинает тормозить (если потери большие и свап на HDD то визуально он виснет), лично для меня это так же неприемлимо, как и начало работы oom-killer'а.
Зачем мне эта «запасная» память? И совершенно логичный вопрос, который и показывает абсурдность вашего подхода: что делать, когда заканчивается запасная память, ведь, о боже, запускается oom-killer?
Когда у меня раньше было мало памяти и куча свапа, а ССД еще не было, так что он был на жестком, то когда система начинала свапиться, я запускал «ручной oom-killer»: Alt+SysRq+F, потому что терпеть это безобразие невозможно. На ssd это работет немного лучше, но все равно garbage.
Коллега, вам правильно советуют почитать, как Линукс работает с памятью, а вы все «про запасную память». Линукс использует своп далеко не только как «запасную память». Вы правы в том, что проблема нехватки памяти не решается добавлением свопа, но вы также неправы, если считаете, что своп больше ни за чем не нужен, кроме как быть подменой оперативной памяти в случае ее нехватки. Ядро запросто может скидывать и скидывает в своп страницы, которые использовались например при инициализации приложения, но в данное время не используются. Если вы посмотрите на вывод vmstat с любого Линукса, то вы часто увидите там ненулевые значения so (swap out) — то есть идет выгрузка страниц на диск. И в этом нет ничего страшного, это нормальный процесс работы с памятью. Страшно бывает когда долго держатся ненулевые значения si (swap in) -то есть идет загрузка страниц с диска. В обычном режиме работы такое происходит крайне редко.
Пока в комментах, к свопу подходили только со стороны запасной памяти.
Насчет выгрузки неиспользуемых страниц, даже сторонники свапа однозначно говорят что это зло, так как приводит к тормоза при открытии ранее запущенных спящих программ и борятся с этим установкой swappiness в 0, тем самым переводя в свап в режим «запасной памяти», и полностью исключая описанное вами поведения.
Так что в данный момент вы противоречите своим же стронникам.
А теперь, чтобы вам не быть уже совсем троллем, прошу привести реальные значения swap out.
Хотя особого смысла нет, так как вы предлагаете худший способ: компьютер, где достаточно памяти заставить тормозить, используя диск. Можете написать статью с другими вредными советами.
Отказываясь от swap, ты уменьшаешь размер дискового кэша.
Пруф?
В Linux дисковый кэш — динамический. Под кэш используется незанятая память. Отключая swap, ты уменьшаешь количество свободной памяти.
Swap всё же хорош только как временная мера. Он сильно замедляет работу системы, вплоть до полного отказа (см. thrashing). При хронических нехватках памяти помогает только апгрейд. Из (не только) моего личного опыта: в большинстве случаев лучше позволить OOM-killer прибить что-нибудь (например, веб-сервер) и вызвать дополнительный алерт в системе мониторинга, чем иметь безбожно тормозящую машину, на которую при определённой «удаче» может быть невозможно попасть.
На моих серверах нет ничего лишнего, что можно было бы прибить (как, впрочем, и на десктопах). Swap — не временная мера. И его отключение не решает проблему, а только усугубляет.
На мой взгляд, если системе нужно зачем-то лезть в swap, особенно когда на сервере нет ничего лишнего, то это указывает на нехватку RAM. На последних нескольких работах было предпочтительнее, чтобы сервер упал, чем тормозил. Расскажите про своё видение. Как именно отсутсвие swap усугубляет проблемы при условии, что RAM в сервере достаточно для нормальной работы +10%-20% на неожиданности?
>На мой взгляд, если системе нужно зачем-то лезть в swap, особенно когда на сервере нет ничего лишнего, то это указывает на нехватку RAM.

По большому счёту я согласен, хоть это и не всегда так.

>На последних нескольких работах было предпочтительнее, чтобы сервер упал, чем тормозил.

Я не могу себе представить, зачем нужен неработающий сервер. Лучше его выключить, чтобы не тратить электричество.

>Как именно отсутсвие swap усугубляет проблемы при условии, что RAM в сервере достаточно для нормальной работы +10%-20% на неожиданности?

Всё предусмотреть невозможно, тем более, добавление swap ничего плохого в плане производительности не добавит.
> Я не могу себе представить, зачем нужен неработающий сервер. Лучше его выключить, чтобы не тратить электричество.

Вот например копии приложения работают на нескольких серверах, запросы к которым проходят из прокси, непосредственно подключенного к интернету. Если один из них начнёт тормозить, то некоторые запросы будут обрабатываться сильно медленно. И это будет как раз ситуация, когда сервер лучше бы выключить, чтобы не тратить электричество зря.

Пусть лучше упадёт. Прокси перекинет пользователей на другие сервера, а с проблемным можно спокойно провести разбор полётов. Возможно воткнуть ещё несколько планок оперативной памяти :).
Ну, то есть лучше этот сервер выключить. Либо решить проблему производительности.
Ну то есть да. Но проблема производительности возникает неожиданно и пусть лучше он сам вырубится, когда она возникнет.
А как включение свапа освобождает физическую память???????
Выгружая редко используемые страницы на диск. Не тупи.
оо, трололо уже на оскорбления перешел.
Прочитай еще раз коммент habrahabr.ru/post/234653/#comment_7915649 и где там оно хоть мегабайт выгрузило-то?
Про околонулевой хитрейт линуксового кэша, который фильмы забирает в кэш и говорить не буду.
Тебе показать пример, когда система начинает использовать swap при ненулевом кеше? И на личности я не переходил, это констатация факта. Что делать, если ты не можешь понять элементарные вещи?
Я отказался от свапа и размер кэша у меня не уменьшился, пруфы я привел.
Так что ты хотел сказать? Кроме ничем не подтвержденных слов и жирного троллинга пока ничего.
Обоснуй, почему система решила использовать swap, а не уменьшить размер кеша:
# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  7  64448  34928  35184 2342880   65  153  1949   989 1816 2135 10 17 58 14  0

# free
             total       used       free     shared    buffers     cached
Mem:       4048252    4020672      27580    2133376      29532    2397880
-/+ buffers/cache:    1593260    2454992
Swap:      4194300     136616    4057684

# cat /proc/sys/vm/swappiness 
60
Воу, целых 60 мегабайт кэша, хитрейт у которого на дектопе так и так ноль, это *ПОИСТИНЕ ОГРОМНЫЙ* ПРИРОСТ.
Я ничего объяснять не буду, пока ты мне не расскажешь почему у меня до сих пор ноль в свап ушло. А то тоже хочу сэкономить пару десятков мегабайт для кэша, в который уйдет фильм, который торрент качает.
Жги дальше.
Параметр cached ты специально игнорируешь?
А что о нем сказать?
Ну скажи что-нибудь, ведь это дисковый кеш. А ты пытаешься доказать, что система от него откажется перед использованием swap. Я же тебе показал, что это не так.
Я нигде ничего подобного не писал.
А твои сэкономленные 60 мегабайт под кэш выглядят просто смешно, особенно учитывая то что в линуксе очень тупой алгоритм кэширования, который на десктопе, кэшируя фильмы, картинки да музыку, выдает околонулевой хитрейт.
Да боже, даже на серверах он выдает рекордные ~0%: blog.famzah.net/tag/filesystem-cache-hitmiss-ratio/
Хотя нет, карта в доте 2 второй раз запускается быстрее почти любого win-компьютера.
какие 60 мегабайт, я про чуть более чем 2Гб.
Прочитай свой же пост, у тебя
swpd = 64448, то есть ты «освободил» под дисковый кэш аж целых 60 мегабайт, вау!
Так что там про хитрейт fullhd фильмов в кэше?
>swpd = 64448

И что? Ну сделал бы я копипасту чуть попозже, было бы больше в свопе. Что это меняет? Я тебе показал процесс активного свопинга при более чем 2Гб в кеше.
Во-первых, не пытайтесь меня запутать, пожалуйста. В статье вы предлагаете вообще не использовать свап. И тут же приводите пример людей, которые используют свап со swappiness=0. Так это, как говорится, две большие разницы. В данном случае, скорее, вы сами себе противоречите.

Во-вторых, какие вредные советы я даю? Использовать свап — это что ли вредный совет? Кто мешает, вашими же словами, создать свап со swappiness=0? Вредный совет — это именно не использовать свап. Так вы только значительно ускоряете приход ООМ. Где гарантии, что оперативной памяти всегда будет хватать, м?
Ответа на мой вопрос не вижу, так что на ваши отвечать тоже не буду.
Кстати, решил проверить вашу теорию, на практике swap out ровно ноль:

root@Gordon01-PC:/# cat /proc/sys/vm/swappiness 
60
root@Gordon01-PC:/# free -m
             total       used       free     shared    buffers     cached
Память:      11710      11136        574        231        342       5918
-/+ буферы/кэш:       4875       6835
Swap:         1999          0       1999
root@Gordon01-PC:/# vmstat 
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 588116 350680 6060312    0    0    16    44   97  135  6  1 91  2  0

Хорошая теория, хорошая попытка.
НЛО прилетело и опубликовало эту надпись здесь
unstable & unusable
НЛО прилетело и опубликовало эту надпись здесь
Видеобенчмарк, который я запускал и так показывает большую производительность на linux, чем на win, так что скорее всего профит от MicroXWin только теоретический. Это и логически понятно, если вспомнить в какие года создавался X-сервер.
НЛО прилетело и опубликовало эту надпись здесь
Прекращайте заниматься теорией, занимайтесь практикой.
Офигенно крутой посыл от человека, который только теоретизирует! Продолжайте.
Рекомендую еще запустить Windows, подвигать окошком и найти там 0,5%, тов. сказочник.
Я не понял, это всё неправда про 15% процессорного времени для подвигать окошко?
15%
Не 15, а 13.
Нет, правда, но на винде точно так же.
Но времена, когда окошки рисовались напрямую GDI'ем прошли с уходом Win95.
Так что на калькуляторе MicroXwin может и даст какой-то профит, но на мощном железе это будут сотые доли процента. Короче, из той же серии экономии 60 МБ из 12 ГБ оперативки свапом.
А тот факт, что MicroXwin еще не пользуют на каждом десктопе лишний раз показывает, насколько это важная проблема.
НЛО прилетело и опубликовало эту надпись здесь
Я думаю, вы специалист по никсам, и понимаете, что проблема не в том, что Иксы занимают 30 мб против 500 кб, а в том что это 30 мегабайт КОДА, который выполняется?


Во первых 30 мегабайт занятых процессом это не обязательно 30 мегабайт именно кода. Сюда входят и данные и так далее.

А во вторых и в самых важных времена, когда 30 мегабайт кода были безусловно лучше 500 килобайт кода для PC давно в прошлом (мы говорим о размере бинарников конечно). В данный момент 30 мегабайт быстро работающего кода гораздо лучше 500 килобайт кода работающего медленно. Да и вообще я давно уже слышал от многих, что размер значения на самом деле не имеет :).

Если серьезно, то вот если бы вы скомпилировали это (ну или Wayland\Mir), провели реальные тесты и написали статью — вас бы многие поблагодарили.


Да, если вы и вправду понимаете почему от иксов надо отказываться в пользу Wayland, напишите статью. В том числе как и где иксы тормозят. Можно без тестов. Я лично скажу большое спасибо. Потому, что я в общем чувствую, что это так, но вот обосновать не могу.
НЛО прилетело и опубликовало эту надпись здесь
Ну как так можно? Русским по-белому ведь написано, «размер библиотек».


Вот это как-то неожиданно. Где написано «размер библиотек»? В вашем коментарии не написано, в вики тоже нет.

Это не данные, это тот код, который загружается в память.


30 мегабайт быстрого и отлаженного кода по прежнему лучше 500 килобайт медленного.

И что бы там не говорили про размер, уже лет 10 все линукс-сообщество осознает, что X-сервер — тормознутый, именно за счет кусков ненужного кода и манипуляций с данными.


Я думал иксы тормозят из-за клиент серверной архитектуры в основном.

С ходу поднимаемся к моему скриншоту с 13%, и включаем логику. Всего у нас 100%. 13 из них тратится на Xorg, который к тому же при этом нихрена не делает.


Но ведь не может быть, чтобы 13% было и на мощном процессоре и на слабом? На i7 наверное меньше процентов, чем на Pentium 4? Или нет?

Как только появляется более ресурсоемкое приложение, Flash Player, например — общая загрузка процессора оказывается не 70%, а 93.


А вот в том, что пробема флеша напрямую связана с иксами я сильно сомневаюсь. Если бы это было так, то подозреваю, что тормозило бы всё, включая игры, а они не тормозят. И если бы вы написали статью, где доходчиво написано почему флеш тормозит из-за иксов, было бы просто замечательно.
Я поверхностно проанализировал и сравнил вывод графики в виндах и линуксах, насколько мне конечно позволяют мои скудные знания. Использовал для этого видеочат на flashе. Под линуксами он тормозит. Задержки, и все такое. Под виндами не тормозит.
Он тормозит из-за стандартного шедулера, с BFS он перестает тормозить. Бородатый баг. ИЧСХ, если следовать советам из моей статьи — проблема уйдет. /coolface
То есть у современной Windows те же проблемы при передвижении курсора мыши, что у современных Линуксов? Я думал, что как раз их у Окон нет.

И мне немного непонятно как это — сначала 13 процентов, а потом сотые доли процента. Вы имеете в виду, что 13 процентов отжирается только на слабом процессоре или что-то другое?
Какой запасной своп для свопа, что за глупости. Всегда можно создать sparse файл на сколько вам надо гигабайт и подключить его как своп. Когда необходимость в нем пропадет, просто освобождаете его и удаляете.
>> От производительности оперативной памяти мало что зависит, от нее не увеличится FPS в играх и не станут быстрее запускаться приложения.

Вот ведь инженеры дураки — всё ускоряют и ускоряют, ставят несколько каналов памяти, борются за каждый такт.
Ага, особенно когда новые версии DDR в первых реализациях работают медленнее из-за таймингов, зато по циферкам частота выше!
По вашей логике нужно всем перейти на DDR1, у которой самые низкие тайминги, ведь частота и как следствие пропускная способность мало на что влияют.
новые версии DDR в первых реализациях
Я живу на ssd с btrfs(с оптимизациями) на 2 раздела /tmp в оперативке и это пушка. Многое перепробовал и несколько раз терял данные, раздел /home и / нужно размещать в разных разделах. В случаи краха и бекапа(разделов) и восстановления системы в предыдущим состоянии, к тому же snapshot btrfs круть
НЛО прилетело и опубликовало эту надпись здесь
Могу только сказать что в убунте с этим никаких проблем.
Подскажите, какое ядро мне качать для моего Linux Mint 17.1 Cinnamon x64 чтобы применить pf-kernel патчи?
uname -a
Linux anonymous 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Смущает то, что у меня 3.13.0, а тут минимальная версия 3.13.1. И, кстати, что значит цифра 37 после версии ядра? И можно ли например взять и поставить сразу 3.17?
Насчёт дефиса в 3.13.0-37: возможно, это версия сборки внутри дистрибутива. По крайней мере в ArchLinux так. То есть, например, версия ядра может не поменялась, но в текущей версии для данного дистрибутива нужно что-то изменить. Как это сделать, ведь итак уже ведётся версионирование? Чтобы не вызывать путаницу, решили приписывать эту версию после дефиса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории