Несколько вопросов, на которые никто не ответил в другой теме

> поскольку, если всё рухнет, то систему будет возможно поднять.

возможно поднять.

Могу сделать так, что будет невозможно поднять систему, недорого.)

> Имеет ли смысл

Имеет смысл сделать так:

1.5 гб swap и всё остальное /

В некоторых случаях вот так:

1.5 гб swap, 10 гб / и остальное /home.

Есть варианты что сделать со вторым хардом, я бы форматнул в ext4 и бросил бы пару симлинков в /home для музыки или фильмов.

А ты уже второй день надрачиваешь какую-то херню.

http://www.yaplakal.com/uploads/post-2-12035890365497.jpg

Я ЗА БАН :)

Молодец. Но твой тихий голос не нужен и не имеет значения.

> Есть варианты что сделать со вторым хардом, я бы форматнул в ext4 и бросил бы

пару симлинков в /home для музыки или фильмов.

Ну, как-бы, тут конкретные вопросы.
Та тема немного отличается. :-\

А ты уже второй день надрачиваешь какую-то херню.

Ну и что? Ты так говоришь, как-будто это что-то плохое.

http://www.yaplakal.com/uploads/post-2-12035890365497.jpg

Знаю-знаю... Посмотри на это с другой стороны: мне уже два дня никто не может толком ответить (чушь не в счёт). Вопросы здесь по пунктам. Где ответы? Спама - море. Каждый - гений. По теме - стремится к нулю. Собственно, потому и «шёл второй день»... Причём тут я?

1. «Не хочется использовать initrd.» и «При установке, стоит ли делать все разделы на LUKS, >>включая корень<<, для простоты?» противоречат друг другу. Определись с тем чего же тебе надо.

2. Стоит делать /tmp разделом. Debian Lenny? Деточка а зачам тебе /tmp в tmpfs + еще и swap? В этом --> «/tmp в tmpfs» есть огромный смысл на SSD а кроме того Gentoo-шнеки тебе еще могут подсказать один способ применения твоего лишнего ОЗУ… Но 700Мб это ерунда.

4. Возможно сделать / на LVM, но при этом без использования initrd никак не обойтись.

>Мало памяти (768 Мб).

сделать tmpfs для /tmp?

Не стоит.

2 - не стоит.
4 - нет, только с initrd.

Стоит ли делать swap на двух физ. дисках, используя LVM том с перемежением? Скорость второго диска выше скорости первого.

Если только в целях увеличения срока службы диска, но имхо не стоит.

1. При установке, стоит ли делать все разделы на LUKS, включая корень, для простоты? Или сделать только /home, swap, /tmp, /var? Не хочется использовать initrd

Не стоит, лишняя трата ресурсов.

2. Мало памяти (768 Мб). Стоит ли делать /tmp разделом? Или просто достаточно расширить swap и сделать tmpfs для /tmp?

С таким объёмом памяти, /tmp в tmpfs не нужно. Да и не с каким объёмом памяти не нужно.

3. Один физический том LVM может включаться в две группы?

Нет.

4. Возможно ли сделать / на LVM, но не используя initrd? Аналогично для LUKS?

Ни то, ни другое нельзя. В initrd включен скрипт для инициализации и того, и другого.

-. Стоит ли делать swap на двух физ. дисках, используя LVM том с перемежением? Скорость второго диска выше скорости первого.

А вот тут надо тестировать. В теории, максимум производительности ты получишь, разместив swap на обоих дисках без использования LVM. Ядро само умеет правильно использовать несколько разделов swap.

-. В кратком руководстве по LVM в Gentoo написано, что / не стоит делать на LVM, поскольку, если всё рухнет, то систему будет возможно поднять. Имеет ли смысл, если CD-ROM не планирует ломаться?

Я с этим руководством не согласен. Использую Gentoo (и на серверах, и на десктопах), везде корень на LVM. Так удобнее.

> Не стоит, лишняя трата ресурсов.
Т.е., на LUKS только необходимые разделы?

Да и не с каким объёмом памяти не нужно.

Почему?

А вот тут надо тестировать.

В теории, максимум производительности ты получишь, разместив swap

на обоих дисках без использования LVM.

Ядро само умеет правильно использовать несколько разделов swap.

Тут в другой теме писали, что там криво реализована работа с двумя разделами. В принципе, я могу потом протестировать просто добавив swap раздел. Если немного поизвращаться (сделать ещё одну группу и т.д.), то возможно и с LVM-ом.
Но остаётся вопрос: как протестировать?

Я с этим руководством не согласен. Использую Gentoo (и на серверах, и на десктопах), везде корень на LVM. Так удобнее.

Хм... Обидно, что не обойтись без initrd. :-(

P.S.:
Спасибо за хороший ответ.

> 2 - не стоит.
Почему?

Если только в целях увеличения срока службы диска, но имхо не стоит.

А как на скорость это повлияет? А срок службы разве сильно уменьшается? Swap используется интенсивно (в данном случае, учитывая объём памяти)?

> 1. «Не хочется использовать initrd.» и «При установке, стоит ли

делать все разделы на LUKS, >>включая корень<<, для простоты?»

противоречат друг другу. Определись с тем чего же тебе надо.

Тут нет противоречия. Либо сделать два раздела LVM и зашифровать, либо шифровать отдельно, что проще? В этом случае, и так два раздела получается: всё, что на /hda, второй логический lvm_home. Но, в общем, - проще сделать всё на LUKS.

2. Стоит делать /tmp разделом. Debian Lenny?

Деточка а зачам тебе /tmp в tmpfs + еще и swap?

Дедушка, а в чём тут проблема? Некоторые (не про меня речь) так делают. Или в ваше время такого не было?

В этом --> «/tmp в tmpfs» есть огромный смысл на SSD а кроме того

Это понятно. Скорость, всё-равно, выше, даже несмотря на swap.

Gentoo-шнеки тебе еще могут подсказать один способ применения твоего лишнего ОЗУ… Но 700Мб это ерунда.

В смысле?

> /tmp в tmpfs + еще и swap?
Вообще-то, вопрос не так прост, как кажется. С одной стороны моих крайне скудных познаний по механизмам управления памятью недостаточно, чтобы что-то однозначное сказать, плюс, если приплести сюда всякие кэширования записи и прочую фигню, становится вообще мутно и не укладывается в голове.
С другой стороны, люди написали tmpfs. Скажи зачем? Почему они её сделали свопируемой? Каковы причины? С учётом того, что ведь есть ещё и ramfs, которая не свопируется...

>> Gentoo-шнеки тебе еще могут подсказать один способ применения твоего лишнего ОЗУ… Но 700Мб это ерунда.

В смысле?

Примотировать туда /var/tmp/portage, но 700Мб это ерунда. :)

Понятно. :-)

Т.е., на LUKS только необходимые разделы?

Да

Да и не с каким объёмом памяти не нужно.

Почему?

tmpfs, как правило, нужен в тех случаях, когда нет возможности использовать блочные устройства на запись, например, Live CD, или снизить вероятность записи (SSD). Использовать его на обычном десктопе без SSD смысла нет, так как всё равно все операции кешируются.

нас много :) хотя не в курсе, почему тебя забанили

> когда нет возможности использовать блочные устройства на запись, например, Live CD, или снизить вероятность записи (SSD). Использовать его на обычном десктопе без SSD смысла нет, так как всё равно все операции кешируются.
Но, если вероятность записи снижается, в общем повышается скорость? Или нет?

> нас много :)
Он - один. :-)

хотя не в курсе, почему тебя забанили

Из-за срача. Модератора запарило вычищать тему.

> Из-за срача. Модератора запарило вычищать тему.

тоже мне. обленился нынче модератор

Ну так, навык повышения собственной важности растёт с годами.

>> 2 - не стоит.

Почему?

Извиняюсь, я имел в виду, что не стоит выносить в tmpfs при таком объеме ОЗУ. Насчет отдельного раздела - в принципе целесообразно, если отформатировать этот раздел в ФС, хорошо работающую с большим количеством мелких файлов (не скажу сейчас какую именно, но можно погуглить сравнения).

Если только в целях увеличения срока службы диска, но имхо не стоит.

А как на скорость это повлияет? А срок службы разве сильно уменьшается? Swap используется интенсивно (в данном случае, учитывая объём памяти)?

Все зависит от задач и системных настроек (vm.swapiness). Насчет скорости, не думаю, что будет большое преимущество, по сравнению с любым другим вариантом.

> Извиняюсь, я имел в виду, что не стоит выносить в tmpfs при таком объеме ОЗУ.
Понятно.

отформатировать этот раздел в ФС, хорошо работающую с большим количеством мелких файлов (не скажу сейчас какую именно, но можно погуглить сравнения).

Рейзер для этого рекомендуют. В принципе, для /tmp надёжность не важна, а по скорости, говорят, она как-раз быстро с мелкими файлами работает.
Хм... Или даже что-то нежурналируемое?

Цитируем a_n

Не хочется использовать initrd.

Цитируем a_n

не используя initrd?

Тебя в детстве покусал initrd? Хотелось бы услышать внятное обоснование его ненужности.

>Рейзер для этого рекомендуют.

у него большие накладные расходы, а судя по кол-ву ОЗУ, можно предположить что комп древний и процессор явно не четерёх-ядерный.

>Хм... Или даже что-то нежурналируемое?

debianmain:/tmp# du -sh
85K	.
debianmain:/tmp# 

Внятного обоснования нет. Когда деревья были большие... :-)
Ну блин, это как-то неправильно: хранить целую ФС с набором инструментов, чтобы смонтировать другую ФС. Причём, эту первую ФС использовать только для этого. То ли дело: напрямую. Смонтировал сразу корневую - и никаких наворотов. :-)
Собственно, это единственный плюс. Незначительное ускорение загрузки ещё возможно назвать.

> можно предположить что комп древний и процессор явно не четерёх-ядерный.
Ну, логично. Так и есть. Самый обычный P4.

85K

сколько можно о каких-то крошках хлеба говорить с таким серъёзным лицом?

:-D Но вы же не хотите сказать, что больше он у вас не бывает (а ведь когда-то 640...)? Я, в той теме, хотел на него 1 Гб потратить. Посмотрев сколько он у остальных (собственно, у вас тоже). Не много, конечно, но и не так мало. Да и от него же зависит производительность?

у него большие накладные расходы, а судя по кол-ву ОЗУ

А что тогда ставить на /tmp?

>Да и от него же зависит производительность?
нихрена от него не зависит кроме возможности записать болванку не фрагментируя соседние разделы, по этому я например создал его как раз на один CD образ.

Хм... Но, кроме того, туда же пишут другие программы? Там хранятся временные файлы, файлы с pid, прочая лабуда, ведь так?

Но, если вероятность записи снижается, в общем повышается скорость? Или нет?

Нет, так как есть кеш.

Ну, уменьшается «частота» сброса данных на диск. Иначе, зачем использовать tmpfs на SDD, если достаточно кэша? Или они отличаются, в данном плане, от жёстких чем-то? Или я неправильно понимаю?

Немного поясню. В случае tmpfs вся fs живёт в памяти, может частично в swap. В случае с обычной фс, в кеш попадает только то, что нужно. Соответственно, tmpfs расходует больше памяти. И вообще, проблема высосана из пальца.

Но, в общем, - проще сделать всё на LUKS.

Так ты таки определись чего же тебе надо. А потом возвращайся ладно? Если ТЫ не знаешь чего ты хочешь то тебе никто не поможет.

Это понятно. Скорость, всё-равно, выше, даже несмотря на swap.

На SSD в этом есть смысл по той причине что ресурс SSD ограничен ога ;) а в ram как бы можно писать ну оооччееень часто.

С другой стороны, люди написали tmpfs.

Потребность в swap на десктопе вменяемого линуксоида пропадает с наличием озу >= 1,5Gb. Использование tmpfs, в случае наличия необходимого кол-ва ОЗУ, ускоряет файловые операции (риск = выкл эл-ва и всему что было в tmpfs ппц)

Ну блин, это как-то неправильно: хранить целую ФС с набором инструментов, чтобы смонтировать другую ФС.

Всё правильно. Для того оно и придумано, чтобы всякую юзерспейсную ерунду в ядро не пихать (в ядре должен быть dm-crypt, но там не должно быть инструментов типа cryptsetup).

Тут в другой теме писали, что там криво реализована работа с двумя разделами.

Можно ссылку?

> Так ты таки определись чего же тебе надо. А потом возвращайся ладно?

Если ТЫ не знаешь чего ты хочешь то тебе никто не поможет.

Ну, как-бы, очень просто: мне надо сделать как правильно. :-)
О чём я и спрашиваю.

Это понятно. Скорость, всё-равно, выше, даже несмотря на swap.

На SSD в этом есть смысл по той причине что ресурс SSD ограничен ога ;)

В повышении скорости? Разве это нужно только на SSD? Я понимаю, что ограничение ресурса не имеет к жёсткому отношения. Но смысл использования на флешках в том, что на них гораздо реже пишется, так, при использовании tmpfs (и реже читается) (ну, вроде, как-то логично, да?)?

а в ram как бы можно писать ну оооччееень часто.

В этом плане жёсткий чем-то отличается? Кроме того, что скорость обращения к ж.д. чаще всего меньше, чем к флешке. Реже будет обращаться - больше «общая производительность». Учитывая то, что tmp часто используется (?), в общем, это будет лучше.
Потому я и спрашиваю: приведёт ли её использование к увеличению производительности? Или я где-то ошибаюсь?

P.S.:
Насчёт «высосанности из пальца» проблемы - не спорю. В общем-то, не проблема даже. По крайней мере, уж что-то, а /tmp всегда возможно подмонтировать туда, куда приспичит. Но интересно как надо и почему?

У меня сложилось впечатление, что во время своппинга основная проблема - это seek-time, а не bandwidth. Так что один канал - не проблема. Но своппинг в линуксе тупой, балансировать нагрузку не умеет, в тонкости не вникает, так что лучше обойтись одним свопом.

http://www.linux.org.ru/forum/linux-install/5301520/page1#comment-5303810 (комментарий)
Изначально я забыл про то,что swap на двух разделах делается без мудрежа штатными средствами. Потом вспомнил, но остались сомнения. Потому вопрос про swap на LVM не был снят.

Ну, как-бы, очень просто: мне надо сделать как правильно. :-)

Нет «как правильно». Можно сделать как угодно. А как именно… - решать тебе.

В повышении скорости? Разве это нужно только на SSD?

С 700Мб ОЗУ ?

Ну да ты хочешь tmp в tmpfs и при этом желая скорости расчитываешь на swap да? Если не хватает ОЗУ то все из tmpfs дружным строем уйдет куда? Правильно в swap. А Swap у нас где? Прааавильно на харде. Ты логику проследил да?

Теперь внимательно… у тебя 700Мб ОЗУ так? Ради интереса заметь сколько сжирает огненнолис/гуглохром ;) а потом еще раз подумай и ответь на вопрос - зачем тебе tmpfs если с твоим кол-м озу все и так полюбому будет в swap? И не проще ли не выделываться до тех пок пока не всунешь овер 2Гб озу.

Потому я и спрашиваю: приведёт ли её использование к увеличению производительности? Или я где-то ошибаюсь?

В твоем случае (700Мб озу ага) это приведет к еще большим тормозам вызванным лишним перебрасыванием данных из tmp (tmpfs) в swap и обратно…

> Нет «как правильно». Можно сделать как угодно. А как именно… - решать тебе.
«Правильных» вариантов в конкретной ситуации совсем немного.

Ну да ты хочешь tmp в tmpfs и при этом желая скорости расчитываешь на swap да?

Да, а также на то, что пока не запущено что-то сильно расходное по памяти, до swap'а дело не дойдёт.

Ради интереса заметь сколько сжирает огненнолис/гуглохром ;)

Ой, бэ. Посмотрел. На винде сейчас ~250. :-(

а потом еще раз подумай и ответь на вопрос - зачем тебе tmpfs если с

твоим кол-м озу все и так полюбому будет в swap?

Вывод ясен.

И не проще ли не выделываться до тех пок пока не всунешь овер 2Гб озу.

Остаётся один вопрос: со swap'ом он работает быстрее, чем с любой ФС (на том же диске) или медленнее? Или нет значительной разницы?

Если не хватает ОЗУ то все из tmpfs дружным строем уйдет куда? Правильно в swap. А Swap у нас где? Прааавильно на харде. Ты логику проследил да?

В общем, ты убил мои надежды. :-) Скорее всего, сделаю /tmp обычным разделом. А раньше казалось, что 256 Мб хватит... :-(

Ну понятно. Есть ещё один вариант... Который я делать не буду, но мне любопытно. %-)

В общем, ты убил мои надежды.

У меня на ~86_64 gnome сразу после старта кушает 150Мб. При том что у меня 3Гб озу и вообще нет swap как такового. И да когда надо то я 2Гб озу юзаю под /var/tmp/portage в которых собирается вообще все ибо зачем мне хард насиловать? ;) за исключением ООо (ибо ставлю только из bin) и gcc.

> У меня на ~86_64 gnome сразу после старта кушает 150Мб.
Ну, у меня 32, естественно и я планирую fluxbox. Так что, не столь затратно. Хотя, и KDE иногда хочется побаловаться...

за исключением ООо

Это что?

Понятно, короче. В моём случае - использовать /tmp разделом единственный верный вариант? И памяти не тратит, и, всё-равно, при использовании tmpfs, всё будет валяться в swap'е. И выигрыш в скорости от отсутствия ФС, при этом, компенсируется перекидыванием из свопа и обратно (что ясно не измеряя). Так?

Там человек, видимо, не разобрался, что у разных облостей swap может быть разный приоритет, и, чтобы сделать работу нескольких swap'ов параллельной, у них должен быть одинаковый приоритет.

Понятно. Т.е., с одинаковым приоритетом, они будут работать, как-будто находятся на RAID0?

В моём случае - использовать /tmp разделом единственный верный вариант?

Нет правильных или не правильных вариантов. У тебя есть мозги и комп. Пробуй…

Да

> Нет правильных или не правильных вариантов. У тебя есть мозги и комп.
Хм... Если бы не было правильных и неправильных, не было бы плохих и хороших админов, например. :-)

Пробуй…

На данный момент, отсеиваю совсем неправильные, используя форум. ;-)

В общем, на все мои вопросы ответили. Спасибо всем.
Особенно Black_Shadow, init_6 и unikoid.