Будущая ос : Arch
Дано : 400 gb HDD, RAM 4 GB , Intel E3300
Нужно :
1) Определиться между x86 или 86_64
2) Найти правильный вариант разметки диска.
Сабж :
Попросили поставить Арч. Информацию написал, исходя из количества рама какую редакцию ставить? Прошу помочь мне с разметкой (решил хотя бы раз разметить по всем канонам). Стоит ли для /root выбирать райзерфс в виде ФС?
Спасибо за ранее!
Правильная разметка диска
doctor_jekyll, если по первому пункту можно порекомендовать 86_64 (да и то найдутся несогласные wink ), то разметка диска и выбор файловой системы — дело о-о-очень индивидуальное, во многом зависит от личных предпочтений и опыта. К тому же вы ни слова не написали о будущем предназначении компьютера.
doctor_jekyll, если по первому пункту можно порекомендовать 86_64 (да и то найдутся несогласные wink ), то разметка диска и выбор файловой системы — дело о-о-очень индивидуальное, во многом зависит от личных предпочтений и опыта. К тому же вы ни слова не написали о будущем предназначении компьютера.
Скорее всего это будет домашняя машинка. Сам думал ставить эту редакцию. Ну а на счет разметки и ФС? Есть какие то мысли? Что бы Вы посоветовали?
для начала:
16-64M - boot (по желанию)
4-8G - swap (по желанию)
20-30G - корень
остальное - home+файлопомойка (в любимой пропорции)
Fat-Zer,
А Файловые Системы?
то бы Вы посоветовали?
С давних пор и до недавнего времени я почти везде (кроме /boot) использовал reiserfs — никаких нареканий!
Если будет отдельный раздел под медиа контент, попробуйте xfs.
По поводу разметки — согласен с Fat-Zer.
Я бы советовал reiserfs - система (корень, /usr, /var), /home - ext4. xfs имеет неприятную особенность - обнулять открытые файлы при пропадании питания, редко но может.
2) Найти правильный вариант разметки диска.
я использую
1) rootfs - корневая система у меня является некой гирляндой, к которой я подвешиваю все остальные ФС. Кроме того, корень содержит необходимый минимум утилит, для загрузки и ремонта системы. Т.о. раздел /boot/ не нужен. В корне так-же содержаться
/bin/ - утилиты для загрузки/ремонта
/boot/ - ядро
/etc/ - системные конфиги
/lib/ - дополнения к /bin/
/sbin/ - административные утилиты, которые не нужны простому юзеру.
ещё в корне есть псевдокаталоги+точки монтирования.
Размер корня примерно 2..5Гб. ФС EXT3. При работе корень практически НЕ используется. Утилиты вроде /bin/sh хранятся на самом деле в памяти, впрочем как и псевдокаталоги. К самому диску обращений нет. Потому тут скорость не нужна, да и надёжность тоже не очень - ибо записи суда нет. Как и чтения.
2) /media/ - каталог, в котором система сама создаёт временные точки монтирования для подключаемых ФС (флешки, компактдиски, и т.д.)
3) /mnt/ - каталог с точками монтирования. В отличие от /media/ тут ФС подключаются при загрузке, и отключаются при выключении компа.
4) /usr/ - каталог с программами. размер примерно 10Гб, ФС EXT4. Файл тут никогда не изменяются, кроме обновлений и установки нового ПО. Скорость не имеет особого значения - файлы отсюда читаются лишь при первом старте программы. Надёжность тоже не очень важна, в силу того, что тут нет записи.
5) /var/ - каталог для изменяемых данных, которые хранятся и после отключения питания. Например здесь лежит база данных, или например файлы, которые закачиваются неделями. Также тут лежат логи. На десктопе ИМХО может быть маленьким, если конечно вы не хотите хранить там временные файлы p2p качалок (не хотите? зря).
ФС EXT4, размер - зависит от назначения компьютера.
6) /tmp/ - каталог с временными файлами. Должен иметь объём хотя-бы 10Гб. При этом, часто его использование будет около нуля. Полезен для надёжности, удобства и безопасности. ФС EXT4.
7) swap. нужен. размер 1..2Гб (вне зависимости от количества памяти). полезен для правильной работы OOM Killer'а. Если нет свопа, ООМ может случайно убить не то приложение, своп даёт немного времени на анализ ситуации, и в случае аварии ООМ убивает именно тот процесс, который нужно. Не используется в нормальной работе, и потому на скорость не влияет.
8) /home/ - всё остальное пространство. ИМХО не нужно делить дск на /home/ и файлопомойку, сделайте каталог /home/other/ если вам нужен доступная всем юзерам "папка". Суда же можно смонтировать второй внутренний (не внешний) HDD, если надо.
Зависит от железа ваще-то. Если SSD, то рекомендации могут быть иные, обеспечивающие максимальный срок жизни диска.
А так /home на отдельный раздел, swap=оперативка х2, на все остальное 10 метров будет более чем достаточно.
swap=оперативка х2
Омг, если ТС не будет использовать так называемую гибернацию, то и swap вообще не нужен, а так swap = ОЗУ или 1/2 ОЗУ :rolleyes:
doctor_jekyll, как вариант использовать LVM(разделы сможешь двигать, только место оставь для того что бы можно было делать резайс =) )
Зависит от железа ваще-то. Если SSD, то рекомендации могут быть иные, обеспечивающие максимальный срок жизни диска.
угу. знаю я ваши "рекомендации". например noatime, как это не парадоксально, ведёт к замедлению работы и большему износу SSD. Фокус в том, что часто система сама юзает atime, а если его нет, то приходится анализировать и менять содержимое файла. Это дольше и дороже смены атрибута.
swap=оперативка х2
вы когда из криокамеры выползете? :[
даже на 384Мб ваш совет довольно глуп (подразумевается, что на системе с 384Мб и HDD тех-же лет).
то и swap вообще не нужен, а так swap = ОЗУ или 1/2 ОЗУ
swap не должен использоваться.
потому его размер не зависит от размера RAM. он либо отсутствует, либо имеет объём около 1Гб (для надёжной работы).
swap не должен использоваться.
потому его размер не зависит от размера RAM. он либо отсутствует, либо имеет объём около 1Гб (для надёжной работы).
В каком смысле "не должен использоваться"?
Я неоднократно наблюдал, как при копировании большого количества файлов (десятки Гб) у меня на сервере под Ubuntu 11.04 система сжирает всю доступную память, а потом начинает с удовольствием использовать SWAP.
В каком смысле "не должен использоваться"?
в самом прямом.
Я неоднократно наблюдал, как при копировании большого количества файлов (десятки Гб)
вы можете писать по-русски? число файлов измеряется в штуках, а не в гигах или литрах.
у меня на сервере под Ubuntu 11.04 система сжирает всю доступную память, а потом начинает с удовольствием использовать SWAP.
как и чем вы копировали?
cp * TARGET/
что-ли? дык bash раскрывает звёздочку в отсортированный текстовый список файлов, который очевидно занимает N*(M+1) байт, где N число файлов, а M средняя длинна имени в байтах, которая для русских файлов вдвое больше чем в символах. ИЧСХ этот кусок памяти невыгружаемый в своп, ибо доступ к нему случайный. Вот ОС и кидает в своп что-то другое. ИЧСОХ, со временем ещё хуже, ибо там коэффициент пропорциональности ещё больше, а именно N*(M+1)*log(N) в среднем, а иногда и все N*(M+1)*N.
В данном случае, ваш сервер работает в аварийном режиме, и скорее всего недоступен клиентам. Скажите спасибо, что у вас вообще всё не рухнуло.
В данном случае, ваш сервер работает в аварийном режиме, и скорее всего недоступен клиентам. Скажите спасибо, что у вас вообще всё не рухнуло.
+500, Док!
Человек хотел похвастаться, а оказалось что у него проблемы :D
вы можете писать по-русски? число файлов измеряется в штуках, а не в гигах или литрах.
ИМХО именно этим языком и пользуюсь.
Количество файлов.... при последнем копировании было 721 т.шт.
Наутилусом.
как и чем вы копировали?
дык bash раскрывает звёздочку в отсортированный текстовый список файлов, который очевидно занимает N*(M+1) байт, где N число файлов, а M средняя длинна имени в байтах, которая для русских файлов вдвое больше чем в символах. ИЧСХ этот кусок памяти невыгружаемый в своп, ибо доступ к нему случайный. Вот ОС и кидает в своп что-то другое. ИЧСОХ, со временем ещё хуже, ибо там коэффициент пропорциональности ещё больше, а именно N*(M+1)*log(N) в среднем, а иногда и все N*(M+1)*N.
Спасибо за объяснение. А то я в некотором удивлении был от таких причуд с памятью. Но только своп используется уже после того, как память полностью заполнена ( 2Гб). Да и версия, что эти списки висят в памяти ВСЁ время, мне кажется странной.
В данном случае, ваш сервер работает в аварийном режиме, и скорее всего недоступен клиентам. Скажите спасибо, что у вас вообще всё не рухнуло.
Ну клиентам он в эти моменты совсем не нужен. Собственно сервер бэкапный, на него копируются данные с основного сервера и всех компьютеров пользователей. А раз в две недели делается копия бэкапной директории. В это время не то что пользователей нет, уже все операции копирования закончены.
А собственно почему рухнуть то должно? Система не умеет корректно обрабатывать запросы на память? Нет возврата неиспользуемых сегментов? Явно, чо при копировании, как бы не обрабатывались списки в памяти, если эти процедуры написаны корректно, то 3,5 Гб ( свободное ОЗУ + swap) не нужно.
2Vadimsky:
Хвастают, демонстрирую крутость и пр... обычно прыщавые юнцы из линуксоидов.
Т.е. настойчивая рекомендация системы при установке создать этот раздел — чистая блаж?
swap не должен использоваться.
Наутилусом.
на сервере? (АДМИНЫ!!! где смайлик?! даже два - сажа и фэйспалм)
Но только своп используется уже после того, как память полностью заполнена ( 2Гб).
угу. это нормальное поведение: память на порядки быстрее, потому заполняется сначала она, а потом уже своп.
Да и версия, что эти списки висят в памяти ВСЁ время, мне кажется странной.
эх...
а мне не кажется. К тому-же так оно и есть. Ибо процесс сортировки - процесс со случайным доступом, и сортированная память не свопится. Свопится что-то другое, например то, что под вашим наутилусом (на раб столе). Потом, с окончанием сортировки, начинается собственно копирование, и если свернуть в этот момент наутилус, будет заметно торможение. Это изнанка достаётся из свопа. Если конечно ОС засвопила именно изнанку (не обязательно).
Система не умеет корректно обрабатывать запросы на память?
на вашем однозадачном сервере вам нечего боятся.
а вообще да, не умеет. Эта задача не разрешима.
Явно, чо при копировании, как бы не обрабатывались списки в памяти, если эти процедуры написаны корректно, то 3,5 Гб ( свободное ОЗУ + swap) не нужно.
гы... :(
2Гб вам недостаточно, а вот 3.5 хватит на всё? Очевидно - нет.
Т.е. настойчивая рекомендация системы при установке создать этот раздел — чистая блаж?
вы хоть читать-бы научились, ей б-гу :(
Не используется в нормальной работе
А в случае аварии (исчерпания памяти) очень даже и используется. Что вы и наблюдаете.
ЗЫЖ в следующий раз соизвольте пожалуйста прочитать всю тему, а не один пост.
[quote=из бывших]Но только своп используется уже после того, как память полностью заполнена ( 2Гб).
угу. это нормальное поведение: память на порядки быстрее, потому заполняется сначала она, а потом уже своп.
Да и версия, что эти списки висят в памяти ВСЁ время, мне кажется странной.
эх...
а мне не кажется. К тому-же так оно и есть. Ибо процесс сортировки - процесс со случайным доступом, и сортированная память не свопится. Свопится что-то другое, например то, что под вашим наутилусом (на раб столе). Потом, с окончанием сортировки, начинается собственно копирование, и если свернуть в этот момент наутилус, будет заметно торможение. Это изнанка достаётся из свопа. Если конечно ОС засвопила именно изнанку (не обязательно).
[/quote]
Т.е. я правильно понимаю, что при копировании система строит в памяти дерево имён и потом его ВСЁ держит в памяти?
Т.е. я правильно понимаю, что при копировании система строит в памяти дерево имён и потом его ВСЁ держит в памяти?
вообще это зависит от реализации, но в любом случае оно не такое большое, чтобы занять значительный объём памяти (если речь не идёт о миллионах файлов)...
простая арифметика: 1000 файлов с именами по 50 байт + накладные расходы ~= 64 килобайта, это на сегодня не цифры...
Да, но 720000 * 50 = 36 000 000
А учитывая, что копируются файлы из бэкапов вин-пользователей, то имена там могут быть длинный, Больше 50 байт.
Так что ИМХО конечно, но эта история мне не нравится. Ну ладно, раз в две недели можно и ручкапи cp - a сделать.
Я правильную команду взял?
вы хоть раз встречали папку такого размера?