Сколько дисков нужно для linux

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

Я решил разметить так:
/ 16 GB
swap по размеру оперативки
/home ?

Вот под /home не могу решить сколько нужно минимум чтобы хватило для типа офисного компьютера (полазить в инете, посмотреть фильмы, работа с таблицами)?
Всякие данные. типа файлопомойки в /home хранить не планирую, для этого выделю в отдельном разделе место сколько свободно останется.

• Вопрос задан более трёх лет назад
• 9521 просмотр

ky0 я не об этом. Я о том, что на рабочих станциях рекомендуется выделять на отдельные разделы var и tmp именно потому, чтобы какое-нибудь приложение пользователя не заполнило весь диск и не положило систему. Да, существуют 5% рута (по умолчанию).

Квоты на /var и /tmp? Многие приложения запускаются от рута в фоне. Вы будете делать квоту руту?
Зачем городить огород, когда можно просто вынести в отдельный раздел. Речь же о рабочих станциях.

Источник

Сколько нужно места для Linux? и .

1.Если я хочу узнать и уметь работать в других ОС. Что лучше? Установить их на отдельный логический диск и загружаться с него или установить в виртуальную машину? !
2. Сколько примерно нужно в среднем емкости для Linux? И для Mac?
3. В какой ОС лучше разбираться, кроме виндоус? Я начинающий программист. Я знаю, что каждая ОС под разніе задачи! А что вы посоветуете? А дистрибутив какой?

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

2. Места, минимум 10 хватит, все остальное что меньше — урезанное и с ограничениями, но лучше 30, причем поделить смето под линукс ручками, а не автоматической установкой, выделив главный раздел /, swap и отдельно /home. В идеале (если для работы) , то 60-80 гигабайт.

3. Для начала Linux Mint — дистрибутив основанный на ubuntu, только с уже подключенными дополнительными репозиториями, в том числе и с играми под линукс, кодеками и прочей приятной мелочью, установка которых у неподготовленного пользователя может вызвать много проблем. Все руководства в инете, которые относятся к ubuntu, а их много, применимы и к этому дистрибутиву.
Прямая ссылка для скачивания образа диска — русский язык для установки выберете в начале этой самой установки.

Видеоуроки по установке и работе с убунту
Книга Ubuntu.Официальный учебный курс. djvu
Мои блоги об установке и настройке linux (ubuntu и mint) http://blogs.mail.ru/list/tansi/tag/linux

1. И то и то
2. 15 Гб выше крыши, и где это у нас Mac-os для простых компов появилась нормальная
3. Мак как и Windows ценится теми кто работает с графикой, музыкой. . В Linux это в принципе нет

Linux — Мандрива, Юбунту, Puppy

distrowatch.com — сайт посвященный linux дистрибам

1 — качать- mirror.yandex.ru (официальное зеркало линукс дистрибутивов и официальный репозиторий) , либо с официальных сайтов (с варезников и торрентов не качаем)
2 — по поводу софта — подключаешь репозитории и в менеджере пакетов ищешь, то что тебе надо
3 — поддержка ntfs — называется ntfs -3g, уже в последних дистрибутивах идет по умолчанию. .
4 — для новичков — ubuntu/kubuntu, mandriva, linux mint, ultimate edition

linuxforum.ru
mdv-club.ru
ubuntologia.ru
ubuntu.ru

ubuntu.ru
linuxmint.com
ultimateedition.info
sidux.com
debian.org
calculate-linux. org
gentoo.ru
archlinux. org. ru
mandriva.ru

уберешь пробелы, там где они стоят

Так просто — никто не ответит.
Линуксы — как дети — все разные, с разными возможностями, все
дети любимые.

Полностью готовенькая — Мандрива для Интернета,
SUSE — интересная штучка для офиса, печати и сканирования.
Мандрива2009 я ставил на 2Gb флешь по минимуму.
Средний минимум обычного Linux’а — около 4 Gb.
Если все основные функции — то 10-20 Gb уже уже будет хватать.
Обратите внимание,
нужно диск правильно разграфить для Линукса
(например работать будет, но если захотите доустановить или что-нибудь много понакачать — то нужно место готовое иметь) .
Мандрива — лучше всех диск делит — там есть варианты — посмотрите на возможности регулирования размера разделов.
Совмещать с Windows на одном HDD — можно, но лучше не делать это, потому что на первых порах придётся экспериментировать много и можно случайно задеть Windows, если выбирать способ загрузки или задеть Linux.
Конечно, страшного ничего нет, если Вы понимаете, что произошло, всё восстановимо, но нужно не пропустить этот момент.
Мандрива особенно интересно востанавливается при любой поломке путём «обновления» с того же самого диска, с которого первичная установка была.
Рабочий стол — лучше Gnome, тема — Redmond и около того, шрифты регулируются, и физиологично цвет рабочего стола под цвет глаз.
Да, самый богатый — Debian, но это — потом.
И, осторожно с AltLinux — он прикольный и его нужно только на отдельный HDD.

«Мандрива2009 я ставил на 2Gb флешь по минимуму.
Средний минимум обычного Linux’а — около 4 Gb.»

Записал на флешку и установил на HDD? Или ты прям с флешки загружаешься? А с фелшки можно?

«Мандрива — лучше всех диск делит — там есть варианты — посмотрите на возможности регулирования размера разделов.»

Тоесть? Я сразу на один лог. диск установлю и все! Кого она делить будет? Какой лог. диск? Конкретней скажите.

«Совмещать с Windows на одном HDD — можно, но лучше не делать это, потому что на первых порах придётся экспериментировать много и можно случайно задеть Windows, если выбирать способ загрузки или задеть Linux.»

Ну большинство ставят на другой лог. диск! У меня нету второго HDD! 🙁

«AltLinux, Debian» — это дистрибутивы? Они для профессионалов? Сложные? А чем они различаются?

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

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

на маке фишка в том, что большинство его программ очень любят затаскивать контент в домашнюю папку: iTines тянет в Music, iPhoto — в Photos. в итоге чтобы полноценно ощутить преимущества этих программ и их связь с ОС, нужно минимум 60 гигабайт.

200 мб и прописываю туда загрузчик, далее уже в ручную произвожу в нём изменения после каждого апгрейда ядра, так надёжнее.. .
касаемо мака, то изучать нечего, здесь самый гемор подобрать для него железо..

Тебе как легче будет? Чтобы привычки венды не нарушать, и чтобы работало сразу — бери ubuntu. Это лучший вариант для «гуйных» начинающих. Чтото более настраиваемое — debian.

Если нужно сразу все возможности linux, без ущемлений, то gentoo. Времени проведешь много, но и быстрей всего научишься.
Для целенаправленных тру-программеров это лучший вариант. gentoo идет на всех архитектурах процессоров.
http://gentoo.theserverside.ru/book/index.html

Предсобранный вариант — calculate linux.

Если машинка не с двумя+ ядрами, то лучше archlinux.
Предсобранный — Chakra Project.

Источник

Сколько памяти необходимо выделить под Ubuntu?

Хочу поставить Ubuntu себе на компьютер рядом с Windows 7, дошёл до этапа с разделением места на диске (выбрал пункт установить рядом с Windows)

На самом диске, куда автоматически предложило сохранить Ubuntu, имеется 1ТБ памяти, может этот вопрос немного глупый, но сколько необходимо выделить под Ubuntu. Я так понимаю эта память будет выделена именна для этой ОС, для личных же файлов будет задействоваться оставшаяся память на этом диске?!

2 ответа 2

Под саму Ubuntu вполне хватит 100гигабайт (это если на поиграться). А оставшееся место — это место, которое будет оставлено для Windows. Но смотрите аккуратно и не удалите его (если он конечно Вам нужен).

То есть, на приведенном скриншоте, установщик спрашивает, сколько места оставить для Windows, а сколько под Ubuntu.

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

Личные файлы, который Вы будете использовать в Ubuntu, лучше хранить в свободном месте на разделе с Ubuntu. Поэтому, если Вы собираетесь монтировать видео, то лучше взять с запасом, побольше. Если же просто смотреть интернет, то 100 Гб будет достаточно (но я бы взял 200).

update

Специально нашел минимальные требования — диск 25 Гигабайт. Но это все таки минимальные. Там же пишут, что можно и на 8 заставить работать, но уже с области спортивной установки.

Источник

Понимая, как используется дисковое пространство в Linux

Прим перев.: Автор оригинальной статьи — испанский Open Source-энтузиаст nachoparker, развивающий проект NextCloudPlus (ранее известен как NextCloudPi), — делится своими знаниями об устройстве дисковой подсистемы в Linux, делая важные уточнения в ответах на простые, казалось бы, вопросы…

Сколько пространства занимает этот файл на жёстком диске? Сколько свободного места у меня есть? Сколько ещё файлов я смогу вместить в оставшееся пространство?

Ответы на эти вопросы кажутся очевидными. У всех нас есть инстинктивное понимание работы файловых систем и зачастую мы представляем хранение файлов на диске аналогично заполнению корзины яблоками.

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

Размер файла

Что такое размер файла? Ответ вроде бы прост: совокупность всех байтов его содержимого, от начала до конца файла.

Зачастую всё содержимое файла представляется как расположенное байт за байтом:

Так же мы воспринимаем и понятие размер файла. Чтобы его узнать, выполняем ls -l file.c или команду stat (т.е. stat file.c ), которая делает системный вызов stat() .

В ядре Linux структурой памяти, представляющей файл, является inode. И метаданные, к которым мы обращаемся с помощью команды stat , находятся именно в inode.

Здесь можно увидеть знакомые атрибуты, такие как время доступа и модификации, а также i_size — это и есть размер файла, как он был определён выше.

Размышлять в терминах размера файла интуитивно понятно, но больше нас интересует, как в действительности используется пространство.

Блоки и размер блока

Для внутреннего хранения файла файловая система разбивает хранилище на блоки. Традиционным размером блока были 512 байт, но более актуальное значение — 4 килобайта. Вообще же при выборе этого значения руководствуются поддерживаемым размером страницы на типовом оборудовании MMU (memory management unit, «устройство управления памятью» — прим. перев.).

Файловая система вставляет порезанный на части (chunks) файл в эти блоки и следит за ними в метаданных. В идеале всё выглядит так:

… но в действительности файлы постоянно создаются, изменяются в размере, удаляются, поэтому реальная картина такова:

Это называется внешней фрагментацией (external fragmentation) и обычно приводит к падению производительности. Причина — вращающейся головке жёсткого диска приходится переходить с места на место, чтобы собрать все фрагменты, а это медленная операция. Решением данной проблемы занимаются классические инструменты дефрагментации.

Что происходит с файлами меньше 4 КБ? Что происходит с содержимым последнего блока после того, как файл был порезан на части? Естественным образом будет возникать неиспользуемое пространство — это называется внутренней фрагментацией (internal fragmentation). Очевидно, этот побочный эффект нежелателен и может привести к тому, что многое свободное пространство не будет использоваться, особенно если у нас большое количество очень маленьких файлов.

Итак, реальное использование диска файлом можно увидеть с помощью stat , ls -ls file.c или du file.c . Например, содержимое 1-байтового файла всё равно занимает 4 КБ дискового пространства:

Таким образом, мы смотрим на две величины: размер файла и использованные блоки. Мы привыкли думать в терминах первого, однако должны — в терминах последнего.

Специфичные для файловой системы возможности

Помимо актуального содержимого файла ядру также необходимо хранить все виды метаданных. Метаданные inode’а мы уже видели, но есть и другие данные, с которыми знаком каждый пользователь UNIX: права доступа, владелец, uid, gid, флаги, ACL.

Наконец, существуют ещё и другие структуры — вроде суперблока (superblock) с представлением самой файловой системы, vfsmount с представлением точки монтирования, а также информация об избыточности, именные пространства и т.п. Как мы увидим далее, некоторые из этих метаданных также могут занимать значительное место.

Метаданные размещения блоков

Эти данные сильно зависят от используемой файловой системы — в каждой из них по-своему реализовано сопоставление блоков с файлами. Традиционный подход ext2 — таблица i_block с прямыми и непрямыми блоками (direct/indirect blocks).

Эту же таблицу можно увидеть в структуре памяти (фрагмент из fs/ext2/ext2.h ):

Для больших файлов такая схема приводит к большим накладным расходам, поскольку единственный (большой) файл требует сопоставления тысяч блоков. Кроме того, есть ограничение на размер файла: используя такой метод, 32-битная файловая система ext3 поддерживает файлы не более 8 ТБ. Разработчики ext3 спасали ситуацию поддержкой 48 бит и добавлением extents:

Идея по-настоящему проста: занимать соседние блоки на диске и просто объявлять, где extent начинается и каков его размер. Таким образом мы можем выделять файлу большие группы блоков, минимизируя количество метаданных и заодно используя более быстрый последовательный доступ.

Примечание для любопытных: у ext4 предусмотрена обратная совместимость, то есть в ней поддерживаются оба метода: непрямой (indirect) и extents. Увидеть, как распределено пространство, можно на примере операции записи. Запись не идёт напрямую в хранилище — из соображений производительности данные сначала попадают в файловый кэш. После этого в определённый момент кэш записывает информацию на постоянное хранилище.

Кэш файловой системы представлен структурой address_space , в которой вызывается операция writepages. Вся последовательность выглядит так:

… где ext4_map_blocks() вызовет функцию ext4_ext_map_blocks() или ext4_ind_map_blocks() в зависимости от того, используются ли extents. Если взглянуть на первую в extents.c , можно увидеть упоминания дыр (holes), о которых будет рассказано ниже.

Контрольные суммы

Файловые системы последнего поколения хранят также контрольные суммы (checksums) для блоков данных во избежание незаметного повреждения данных. Эта возможность позволяет обнаруживать и корректировать случайные ошибки и, конечно, ведёт к дополнительным накладным расходам в использовании диска пропорционально размеру файлов.

Более современные системы вроде BTRFS и ZFS поддерживают контрольные суммы для данных, а у более старых, таких как ext4, реализованы контрольные суммы для метаданных.

Журналирование

Возможности журналирования для ext2 появились в ext3. Журнал — циклический лог, записывающий обрабатываемые транзакции с целью улучшить устойчивость к сбоям питания. По умолчанию он применяется только к метаданным, однако можно его активировать и для данных с помощью опции data=journal , что повлияет на производительность.

Это специальный скрытый файл, обычно с номером inode 8 и размером 128 МБ, объяснение про который можно найти в официальной документации:

Журнал, представленный в файловой системе ext3, используется в ext4 для защиты ФС от повреждений в случае системных сбоев. Небольшой последовательный фрагмент диска (по умолчанию это 128 МБ) зарезервирован внутри ФС как место для сбрасывания «важных» операций записи на диск настолько быстро, насколько это возможно. Когда транзакция с важными данными полностью записана на диск и сброшена с кэша (disk write cache), запись о данных также записывается в журнал. Позже код журнала запишет транзакции в их конечные позиции на диске (операция может приводить к продолжительному поиску или большому числу операций чтения-удаления-стирания) перед тем, как запись об этих данных будет стёрта. В случае системного сбоя во время второй медленной операции записи журнал позволяет воспроизвести все операции вплоть до последней записи, гарантируя атомарность всего, что пишется на диск через журнал. Результатом является гарантия, что файловая система не застрянет на полпути обновления метаданных.

«Упаковка хвостов»

Возможность tail packing, ещё называемая блочным перераспределением (block suballocation), позволяет файловым системам использовать пустое пространство в конце последнего блока («хвосты») и распределять его среди различных файлов, эффективно упаковывая «хвосты» в единый блок.

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

Разрежённые файлы

Большинство современных файловых систем поддерживают разрежённые файлы (sparse files). У таких файлов могут быть дыры, которые в действительности не записаны на диск (не занимают дисковое пространство). На этот раз реальный размер файла будет больше, чем используемые блоки.

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

Чтобы медленно создать 10-гигабайтный файл, который занимает около 10 ГБ дискового пространства, можно выполнить:

Чтобы создать такой же большой файл мгновенно, достаточно лишь записать последний байт… или даже сделать:

Или же воспользоваться командой truncate :

Дисковое пространство, выделенное файлу, можно изменить командой fallocate , которая делает системный вызов fallocate() . С этим вызовом доступны и более продвинутые операции — например:

• Предварительно выделить пространство для файла вставкой нулей. Такая операция увеличивает и использование дискового пространства, и размер файла.
• Освободить пространство. Операция создаст дыру в файле, делая его разрежённым и уменьшая использование пространства без влияния на размер файла.
• Оптимизировать пространство, уменьшив размер файла и использование диска.
• Увеличить пространство файла, вставив дыру в его конец. Размер файла увеличивается, а использование диска не меняется.
• Обнулить дыры. Дыры станут не записанными на диск extents, которые будут читаться как нули, не влияя на дисковое пространство и его использование.

Например, создать дыры в файле, превратив его в разрежённый, можно так:

Команда cp поддерживает работу с разрежёнными файлами. С помощью простой эвристики она пытается определить, является ли исходный файл разрежённым: если это так, то результирующий файл тоже будет разрежённым. Скопировать же неразрежённый файл в разрежённый можно так:

… а обратное действие (сделать «плотную» копию разрежённого файла) выглядит так:

Таким образом, если вам нравится работать с разрежёнными файлами, можете добавить следующий алиас в окружение своего терминала (

Когда процессы читают байты в секциях дыр файловая система предоставляет им страницы с нулями. Например, можно посмотреть, что происходит, когда файловый кэш читает из файловой системы в области дыр в ext4. В этом случае последовательность в readpage.c будет выглядеть примерно так:

(cache read miss) ext4_aops-> ext4_readpages() -> . -> zero_user_segment()

После этого сегмент памяти, к которому процесс пытается обратиться с помощью системного вызова read() , получит нули напрямую из быстрой памяти.

Файловые системы COW (copy-on-write)

Следующее (после семейства ext) поколение файловых систем принесло очень интересные возможности. Пожалуй, наибольшего внимания среди фич файловых систем вроде ZFS и BTRFS заслуживает их COW (copy-on-write, «копирование при записи»).

Когда мы выполняем операцию copy-on-write или клонирования, или копии reflink, или поверхностной (shallow) копии, на самом деле никакого дублирования extent’ов не происходит. Просто создаётся аннотация в метаданных для нового файла, которая отсылает к тем же самым extents оригинального файла, а сам extent помечается как разделяемый (shared). При этом в пользовательском пространстве создаётся иллюзия, что существуют два отдельных файла, которые можно отдельно модифицировать. Когда какой-то процесс захочет написать в разделяемый extent, ядро сначала создаст его копию и аннотацию, что этот extent принадлежит единственному файлу (по крайней мере, на данный момент). После этого у двух файлов появляется больше отличий, однако они все ещё могут разделять многие extents. Другими словами, extents в файловых системах с поддержкой COW можно делить между файлами, а ФС обеспечит создание новых extents только в случае необходимости.

Как видно, клонирование — очень быстрая операция, не требующая удваивания пространства, которое используется в случае обычной копии. Именно эта технология и стоит за возможностью создания мгновенных снапшотов в BTRFS и ZFS. Вы можете буквально клонировать (или сделать снапшот) всей корневой файловой системы меньше чем за секунду. Очень полезно, например, перед обновлением пакетов на случай, если что-то сломается.

BTRFS поддерживает два метода создания shallow-копий. Первый относится к подтомам (subvolumes) и использует команду btrfs subvolume snapshot . Второй — к отдельным файлам и использует cp —reflink . Такой алиас (опять же, для

/.bashrc ) может пригодиться, если вы хотите по умолчанию делать быстрые shallow-копии:

cp=’cp —reflink=auto —sparse=always’

Следующий шаг — если есть не-shallow-копии или файл, или даже файлы, с дублирующимися extents, можно дедуплицировать их, чтобы они использовали (через reflink) общие extents и освободили пространство. Один из инструментов для этого — duperemove, однако учтите, что это естественным образом приводит к более высокой фрагментации файлов.

Если мы попытаемся теперь разобраться, как дисковое пространство используется файлами, всё будет не так просто. Утилиты вроде du или dutree всего лишь считают используемые блоки, не учитывая, что некоторые из них могут быть разделяемыми, поэтому они покажут больше занятого места, чем на самом деле используется.

Аналогичным образом, в случае BTRFS стоит избегать команды df , поскольку пространство, занятое файловой системой BTRFS, она покажет как свободное. Лучше пользоваться btrfs filesystem usage :

К сожалению, я не знаю простых способов отслеживания занятого пространства отдельными файлами в файловых системах с COW. На уровне подтома с помощью утилит вроде btrfs-du мы можем получить приблизительное представление о количестве данных, которые уникальны для снапшота и которые разделяются между снапшотами.

Источник