Разделение диска 2tb

Я новичок в Linux. Я планирую установить Squeeze на жестком диске 2 тб следующим образом:

  • / – 10gb
  • замена
  • оставшееся место будет содержать / home, около 1.9 тб. Надеюсь, я попытаюсь использовать как lvm, чтобы добавить мой старый 1tb-диск позже

Мой вопрос: должен ли я использовать GPT? или MBR будет просто отлично

если GPT нужна эта схема, это хорошо?

  • / boot – 150mb
  • / – 10gb
  • замена
  • / home (lvm с оставшимся пространством)

материнская плата – это ASRock G41 btw, которая, я думаю, не поддерживает EFI

  • Создание отдельного тома для / var / log / и / var / log / audit /
  • Как я могу восстановить удаленные логические тома LVM?
  • Могу ли я разделить часть / dev / sda / home?
  • Как развернуть раздел LVM2 в Fedora Linux
  • Настройка частной зоны контейнера OpenVZ
  • LVM: отражается ли это? скопировать это медленно?
  • Разница между снимком fsfreeze и lvm
  • обратное расширение объема группы LVM
  • 4 Solutions collect form web for “Разделение диска 2tb”

    GPT или MBR?

    Как сказал @mgorven, либо будет работать на 2TB. Я развернул десятки меток MBR на двухдисковых дисках, и он отлично работает на них. Это действительно ваш выбор. На данный момент я предпочитаю MBR, но это уже изменится.

    UEFI и GPT

    Вы не нуждаетесь в UEFI для записи метки диска GPT на диск, и если вы умны, вы, возможно, можете загрузите диск с меткой диска GPT из не-UEFI ROM (требуется щепотка соли, у меня нет сделал это). Статья в Википедии о GPT содержит некоторую косвенную информацию об этом.

    зон

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

    Разделение диска для Unix

    Вы хотите иметь много файловых систем, потому что (среди прочего):

    • Вы не кладете все яйца в одну корзину. Если одна файловая система повреждена, вы восстанавливаете ее из резервной копии, и жизнь возвращается к нормальной жизни. Если все ваши файловые системы повреждены, есть больше времени простоя, больше проблем, и вы становитесь более раздраженными.
    • Каждая файловая система может быть настроена по-разному по соображениям производительности. Файловая система, в которой вы храните свой MailDir, может иметь сотни тысяч небольших файлов в нескольких каталогах. В файловой системе, где хранятся видеофайлы, есть десятки огромных файлов. Вы можете оптимизировать.
    • Вы можете зарезервировать место в файловой системе и разрешить определенному пользователю использовать его, когда другие не могут. Обычно корень резервирует 5% пространства файловой системы. С несколькими файловыми системами вы можете настроить это (например, файловая система почты может иметь пространство, назначенное почтовому пользователю).
    • Вы упрощаете политику резервного копирования, создавая одну файловую систему для одного резервного носителя. Это зависит от политики резервного копирования и программного обеспечения.
    • С отдельными файловыми системами, например, /home , вы можете иметь несколько операционных систем * nix на одном компьютере и делиться своими файлами между ними, не прибегая к клокам.
    • Вы можете решить системные ограничения. Например, в прошлом некоторые диски не могли загружаться с дисковых блоков слишком далеко от начала диска, поэтому мы сделали бы достаточно маленькую /boot файловую систему, чтобы занять первые блоки диска.
    • Вы можете оптимизировать скорость. Поместите критические файловые системы в самые быстрые зоны диска.
    • Скорость загрузки: fsck в 20G файловой системе быстрее, чем fsck в 1900G файловой системе. Хитроумный выбор периодов проверки может обеспечить вам распространение трасс fsck .

    Возможно, вы не хотите иметь слишком много файловых систем, потому что:

    • Вы квантуете дисковое пространство. Если вам нужно хранить 100G на диске, вы можете обнаружить, что у вас есть 200G бесплатно, но нет единого раздела с достаточным объемом свободного места на диске.
    • Вы ограничены возможностями вашей метки диска. Многие Unices могут помещать только 8 разделов / фрагментов в метку диска, и один из них зарезервирован. MBR не очень ограничен в этом отношении, и GPT позволит 128 разделов, что намного больше, чем вам нужно.
    • Слишком много файловых систем может быть неприятностью для создания и управления.
    • Требования к хранению файлов не так разнообразны.

    Схемы файловой системы

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

    • / (корень)
    • /boot
    • /usr
    • /var
    • /usr/local
    • /tmp
    • /home
    • резервная файловая система

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

    Я также сохраняю резервную файловую систему в конце диска. Я mkfs и использую его для пространства царапин, часто монтируется под /disk1 (соглашение о работе) или /disk/tmp (мое соглашение). Эта файловая система полезна, если я открою новую потребность (я могу удалить ее и создать другую файловую систему или просто перепрофилировать ее), или мне просто нужно много места для царапин.

    Определение размеров

    Это во многом зависит от того, для чего будет использоваться компьютер. Вы можете уйти с действительно маленькими размерами для многих вещей. Мое предложение состояло в том, чтобы использовать LVM (читать дальше) и выделять 10G каждый в /usr , /var и /usr/local (меньше, если вы не планируете компилировать и устанавливать собственное программное обеспечение). Я держу /tmp маленьким, возможно 1-2G. Не имея всех больших файловых систем в корневой файловой системе, это также может быть небольшим: в моем текущем поле есть раздел 2G, и осталось много свободного места. Файловая система /boot может быть очень маленькой, если вы не являетесь разработчиком ядра, или полностью исключены. Недавние компьютеры и последние версии GRUB прекрасно справляются с этим. Если вы хотите, около 200-300 мегабайт будет хорошо.

    LVM

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

    Примерная схема

    • Раздел 1: пространство подкачки (начало диска)
    • Раздел 2: физический объем LVM с группой томов под названием «fs» или что-то еще.
      • Объем fs-root : ~ 2G.
      • Объем fs-usr : ~ 10G.
      • Объем fs-var : ~ 10G.
      • Объем fs-local (сокращение от /usr/local ): ~ 5-10G.
      • Объем fs-tmp : ~ 2G.
      • Объем fs-home : оставшееся пространство минус, возможно, ~ 30G.
      • Объем fs-spare : запасное пространство: ~ 30G.

    На диске 2T с пространством подкачки 8G ваш /home раздел будет 2000 – 8 – 2 – 10 – 10 – 10 – 2 – 30 = 1928G.

    Запасной раздел 30G пригодится, если вам нужно больше места для одного или нескольких других томов. Достаточно легко изменить размеры томов LVM (и ext {2,3,4} файловых систем).

    Обратите внимание, что нет отдельной /boot и что вся ваша загрузочная инфраструктура (ядро и initrd ) находится внутри LVM. Это заставляет некоторых людей беспокоиться, но у меня никогда не было проблем с этим. GRUB может прекрасно видеть внутри физических томов LVM. Если это вас беспокоит, сделайте отдельную /boot около 200 миллионов. Сделайте его либо разделом 2 (созданием раздела LVM PV), либо разделом 1 (нажатием двух других).

    MBR должен хорошо работать на приводе 2 ТБ, но не на чем-то большем. На самом деле не имеет значения, используете ли вы MBR или GPT, если все операционные системы, которые вы хотите использовать, поддерживают его. BIOS не должен поддерживать EFI для загрузки с GPT-накопителя.

    Независимо от того, используете ли вы MBR или GPT, я бы рекомендовал использовать LVM для управления пространством, потому что он намного более гибкий и более легкий для изменения на более позднем этапе.

    Я думаю, вы немного задумались над этим. GPT vs MBR действительно имеет значение, если вы намерены установить несколько операционных систем или переместить диск на другой компьютер. Если вы можете уйти с MBR, вы можете также придерживаться его, особенно если вы используете LVM (что позволяет использовать многие функции, отсутствующие в MBR).

    Что касается размеров разделов, вот несколько хороших правил:

    • Небольшие разделы могут быть раздражающими, так как вы никогда не знаете заранее, сколько вы действительно будете использовать.
    • Большие разделы могут раздражать, потому что они занимают много времени, чтобы строить и проверять. Кроме того, «износ» на файловых системах имеет тенденцию к созданию на основе использования. Помещение всего в один раздел означает, что это наращивание происходит быстрее. Что бы это ни стоило.

    Файловые системы, которые оказываются слишком маленькими, обычно являются драмой. 10 ГБ могут быть легко заполнены двоичными файлами и файлами журналов. У вас много дискового пространства, почему вы так стараетесь экономить на пространстве? Вы пожалеете об этом через некоторое время. Не назначайте дисковое пространство одновременно, оставляйте место для перемещения файловых систем по необходимости. Расширение файловой системы легко, сокращение – нет. Проверьте, что LVM2 может сделать для вас. http://tldp.org/HOWTO/LVM-HOWTO/index.html Не принимайте плохие решения, которые блокируют вас на долгие годы.

    Linux и Unix - лучшая ОС в мире.