Как разделить диск на 22 ТБ?

7 ответов

Простое решение состоит в том, чтобы использовать разделение GPT, 64-разрядную версию Linux и XFS:

  • GPT необходим потому что СТИЛЬ MS-DOS таблица разделов MBR, созданная fdisk ограничен дисками на 2 тебибайта. Так, необходимо использовать parted или другая GPT-осведомленная программа разделения вместо fdisk. (gdisk, gparted, и т.д.)

  • 64-разрядное ядро необходимо, потому что 32-разрядные ядра ограничивают Вас файловыми системами, меньшими, чем Вы просите. Вы или поражаете предел размера на основе 32-разрядных целых чисел или заканчиваете тем, что не были способны обращаться к достаточному количеству RAM для поддержки файловой системы правильно.

  • XFS не является единственным решением, но по-моему это - самое легкое для систем RHEL.

    Вы не можете использовать ext4 для этого в RHEL 6. Хотя файловая система была разработана для поддержки файловых систем на 1 эксбибайт, существует искусственный предел размера тома на 16 тебибайт в версии e2fsprogs включенный в RHEL 6 и его производные. И Red Hat и CentOS вызывают это в их документах. (ext4 предел на 16 тебибайт был значительно повышен в 7 - 50 тебибайтах RHEL .)

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

    Исключив Ваши две выбранных файловых системы, я предлагаю XFS. Это - файловая система по умолчанию в RHEL 7, это было доступно как поддерживаемая файловая система во всем RHEL 6 версий и было бэкпортировано к более поздним выпускам RHEL 5 после того, как RHEL 6 вышел.

Вот процесс:

  1. Проверьте, имеете ли Вы mkfs.xfs установленный путем выполнения его без аргументов. Если это не присутствует, установите инструменты XFS пространства пользователя:

    # yum install xfsprogs
    

    Если это перестало работать, вероятно, потому что Вы находитесь на более старой ОС, не имеет этого в ее хранилище пакетов по умолчанию. Действительно необходимо обновить, но если это невозможно, можно получить это от CentOSPlus или EPEL. Вы, возможно, также должны установить kmod_xfs пакет.

  2. Создайте раздел:

    Так как Вы говорите, что Ваш объем на 22 тебибайта идет /dev/sdb, команды для parted :

    # parted /dev/sdb mklabel gpt
    # parted -a optimal -- /dev/sdb mkpart primary xfs 1 -1
    

    Это заставляет это принимать весь объем с единственным разделом. На самом деле это игнорирует первого 1 мебибайт объема, для достижения  выравнивания на 4 кибибайта, требуемого получить полную производительность от Усовершенствованного Формата жесткие диски и SSD.

    Вы могли пропустить этот шаг и отформатировать весь объем с XFS. Таким образом, Вы использовали бы /dev/sdb в примере ниже вместо /dev/sdb1. Это избегает проблемы выравнивания сектора. В случае объема, что только Ваша основанная на Linux ОС будет видеть, нет никаких оборотных сторон, которые стоит говорить о, но я предостерег бы против выполнения этого на съемном объеме или на внутреннем объеме в мультизагружающемся компьютере, так как некоторые Ose (Windows и macOS, например) предложат форматировать жесткий диск без раздела для Вас каждый раз, когда это появляется. Помещение файловой системы на разделе решает это.

  3. Отформатируйте раздел:

    # mkfs.xfs -L somelabel /dev/sdb1
    
  4. Добавьте /etc/fstab запись:

    LABEL=somelabel    /some/mount/point    xfs     defaults   0 0
    
  5. Возрастите!

     # mount /some/mount/point
    

Если Вы хотите спуститься по пути LVM, вышеупомянутые шаги являются в основном просто более подробной версией второго набора команд в пользователе bsdответ ниже. Необходимо сделать его первый набор команд перед теми выше.

LVM предлагает определенные преимущества по стоимости сложности. Например, можно позже "вырастить" группу объема LVM путем добавления большего количества физических томов к нему, таким образом, создания пространства для роста логического тома ("раздел" отчасти, вид), который в свою очередь позволяет Вам вырастить файловую систему, живущую на логическом томе. (См. то, что я имею в виду о сложности?:))

44
27.01.2020, 19:37
  • 1
    Часть ZFS спорна. Порт Linux проделал длинный путь с 2010, и по сравнению с XFS он имеет много –  TheLQ 18.01.2012, 20:03
  • 2
    Относительно GPT/MBR, не делает это только действительно применяется если /boot часть /? MBR не должен заботиться как большой / то, если это только должно смонтировать маленькое /boot правильно? Я мог быть неправым. –  jonescb 20.01.2012, 06:39
  • 3
    @jonescb: местоположение /boot не имеет никакого влияния на ограничения MBR. При необходимости в разделе более чем 2 ТБ Вы не можете использовать разделение MBR. Это верно, однако, что возможно работать вокруг отсутствия поддержки BIOS для начальной загрузки от GPT путем помещения /boot на фрагментированном диске MBR меньшего размера. После того как ядро произошло, Вы не должны волноваться об ограничениях BIOS, потому что оно знает, как интерпретировать таблицу разделов GPT. Если Ваша машина основана на EFI, Вы не должны делать этого танца, потому что EFI понимает GPT. –  Warren Young 20.01.2012, 08:32

Так же, как альтернатива другим предложениям.
Вы не должны делить диск вообще.
Вы могли простой создавать Группу Объема с одним или несколькими Логическими томами.

pvcreate /dev/sdb
vgcreate data /dev/sdb
lvcreate --name dump -L '100%VG' data

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

mkfs.XXXX /dev/mapper/data-dump #<- XXXX can be ext4, xfs, btrfs, reiser
mount /dev/mapper/data-dump /mntpt
16
27.01.2020, 19:37
  • 1
    LVM является в основном усовершенствованной формой разделения. Бессмысленно использовать LVM, если Вы просто собираетесь создать единственный LV с помощью всего пространства, таким образом, Вы можете также просто mkfs непосредственно на целом дисковом устройстве. –  psusi 17.01.2012, 20:42
  • 2
    никакой LV добавляет инструменты для снимков живых данных, изменяемого размера, несколько копий метаданных; намного более гибкий, чем простая фс на устройстве. 8:39:04 –  bsd 18.01.2012, 05:03
  • 3
    Вам не нужны несколько копий метаданных, когда у Вас нет метаданных (таблица разделов) во-первых. Снимки требуют свободного пространства, как делает добавляющие/расширяющие объемы, следовательно почему оно представляется бессмысленное, если Вы просто создаете единственный логический том с помощью всего пространства сразу. Если Вы хотите функции LVM, то необходимо запустить с меньшего объема, таким образом, у Вас есть много свободного пространства для использования позже. –  psusi 18.01.2012, 18:39
  • 4
    я не рекомендовал LVM в случае этого человека, просто перечисляя его как альтернативу "другому" разделению, не деля ответы/решения. Ее дело читать все ответы, добиваться ее собственного исследования и затем решать, какой план действий лучше всего удовлетворяет ее потребностям. –  bsd 18.01.2012, 19:57
  • 5
    Одно преимущество LVM, даже если у Вас только есть один LV, является им, позволяет Вам легко добавить устройство хранения данных позже. –  plugwash 11.12.2015, 14:01

Вопрос вопросу: Вы спросили, 'как разделить диск на 22 ТБ' и затем в вопросе снова, Вы сказали, Вы просто хотели раздел на 22 ТБ. Таким образом, это - ambiguos в первом месте.

Если у Вас уже есть единственное блочное устройство, которое уже может поддерживать 22 ТБ пространства на нем, то Вы отряды целый раздел на 22 ТБ. Все, в чем Вы нуждаетесь, является файловой системой сверху его, которая сделает устройство монтируемым и применимым для чтения/записи системными процессами. Больше когда-либо у Вас должно быть ядро Linux, работающее в 64-разрядном режиме с модулем/драйвером файловой системы, который поддерживает и масштабируется к 22 ТБ роста данных, может обработать входы и выходы управления данными по (единственному) блочному устройству легко. Производительность является в целом другим размером к нему. В таком случае я решил бы выбрать XFS как моя файловая система, по причине, что это - 64-разрядная файловая система и способный к обработке файловых систем, столь же больших как миллион терабайт. Это поддерживает до 9 ЭКСАБАЙТ.

2^63  = 9 x 1018 = 9 exabytes 

Для получения дополнительной информации на XFS: http://oss.sgi.com/projects/xfs/

При поиске дальнейшего разделения огромного блочного устройства на 22 ТБ то используйте gparted разделять устройство на применимые разделы и затем форматировать их с файловыми системами для создания их монтируемыми.

Кажется, что у Вас есть аппаратный RAID-контроллер, так как Вы упоминаете, что у Вас есть DELL perc RAID-контроллер - который будет означать, что, необходимо сказать, какая конфигурация RAID (точно, какой уровень RAID Вы используете?) и в большинстве случаев, Вы не собираетесь получать полных 22 ТБ пространства для использования, я мог быть неправым все же.

6
27.01.2020, 19:37
  • 1
    я собирался предложить xfs также, но xfs_check возьмет большой объем памяти, и долгое время для выполнения w/22G фс. Между физическим и подкачкой можно было бы быть нужно, по крайней мере, 32G для проверки, это - то, если он когда-нибудь хочет проверить фс на 'дампе' (независимо от того, что это - ;) –  bsd 14.01.2012, 13:43
  • 2
    @bdowning, Вы могли бы хотеть исправить его к 22T фс :) –  Nikhil Mulley 14.01.2012, 13:44
  • 3
    Это - Набег на 22 ТБ 5. У меня есть много дисков :) –  LVLAaron 14.01.2012, 15:20
  • 4
    Это было опечаткой (заскок). У меня есть то же устройство, 10 ТБ, с Меганабегом LSI (та же карта как Dell Perc) –  bsd 14.01.2012, 15:27
  • 5
    @bdowning: xfs_check действительно использует большую память, но упоминания страницы руководства (8): "Отметьте то использование xfs_check НЕ рекомендуется. Используйте xfs_repair -n вместо этого, для лучшей масштабируемости и скорости. ". –  Cristian Ciupitu 29.11.2012, 08:10

Вы не должны нуждаться ни в каком разделении при использовании ZFS, просто создавать пул ZFS на устройстве на 22 ТБ и файловой системе в нем, если Вы не хотите использовать по умолчанию и вот именно. Если по некоторым причинам, шпулька не поддерживает использование целого диска, сначала создает маркировку EFI, и раздел, использующий целое пространство, доступное внутри затем, используют тот раздел для создания пула.

По нескольким причинам я не рекомендовал бы использовать что-либо кроме ZFS для такой большой файловой системы. Самое очевидное - то, если Вы имеете жестокую власть прочь (например: паника ядра или дефицит энергоресурсов), fsck может занять болезненный отрезок времени для восстановления традиционных файловых систем. ZFS, с другой стороны, не нужен fsck, так импортирует пул немедленно.

Обратите внимание, что необходимо повредить аппаратную конфигурацию RAID и использовать эти двенадцать устройств в качестве JBOD для создания пула ZFS с использованием в своих интересах его поддержки программного обеспечения RAID. Если Вашей целью является производительность, Вы могли бы зеркально отразить пар дисков и если Ваша цель максимизируется пространство, Вы могли бы использовать RAIDZ, RAIDZ2 или конфигурацию RAIDZ3. Выполнение его в основном улучшит надежность Ваших данных и отказоустойчивость решения.

4
27.01.2020, 19:37
  • 1
    я знаю это, является старым ответом на старый вопрос, но.... при использовании ZFS, наилучший вариант состоит в том, чтобы уничтожить RAID-массив, настроить RAID-контроллер для JBOD так, чтобы Linux видел каждый отдельный диск, и затем создайте зеркально отраженных пар (меньше способности, высокой эффективности) или RAIDZ/Z2/Z3 (больше способности, тусклой производительности) от отдельных дисков. Вы теряете большую часть преимущества ZFS, если Вы разделяете его на уровни сверху существующего RAID, а не позволяете ему обработать диски самому. То же относится к btrfs. –  cas 15.06.2016, 07:05
  • 2
    @cas Вы определенно правы, обновленный ответ. Я был сфокусирован к вопросу OP, хотя, "как разделить диск на 22 ТБ" и не, "что Вы рекомендуете сделать с моей настройкой дисков". –  jlliagre 15.06.2016, 08:45

Я не уверен, что это - в настоящее время возможное использование стандартной таблицы разделов. В стандартной схеме таблицы разделов объемы ограничены 232 секторами. С 512 байтами за сектор Вы просто выбежали числа для присвоения секторам приблизительно 2 ТБ.

Однако необходимо смочь сделать это при использовании Таблицы разделов GUID вместо стандартной. Таблицы разделов GUID позволяют, чтобы объемы расширились в диапазон зеттабайта. Большинство дистрибутивов Linux является загрузочным от объема GUID, однако никакая версия Windows (за исключением Windows 7 на EFI) в настоящее время не.

Некоторые инструменты как fdisk не могут работать с объемами GUID, однако другие инструменты как GParted могут. После того как Вы создаете свою таблицу разделов GUID, необходимо смочь создать объем с помощью одной из нескольких общих файловых систем, которые поддерживают объем того размера (например, EXT4.)

3
27.01.2020, 19:37
  • 1
    В 32-разрядной системе может быть. Я смог создать раздел на 3.5 ТБ на 64-разрядном сервере Ubuntu, поддерживаемом под версией 8.04 и выше. Разговор о cyberciti.biz/tips / … –  Karlson 14.01.2012, 06:20
  • 2
    К моему знанию Вам даже, возможно, не понадобится таблица разделов для помещения файловой системы на жесткий диск. Плюс согласно OP это не загрузочный диск просто большое пространство дампа. –  Karlson 14.01.2012, 07:47

Если Вы не ищете дублирование или способность поддержать его, можно, вероятно, сделать:

mkfs -t ext4 /dev/sdb
1
27.01.2020, 19:37
  • 1
    Вы попробовали его? Я изменился mkfs указывать файловую систему –  Karlson 14.01.2012, 06:05
  • 2
    @AaronJAnderson объяснение помог бы. –  n0pe 14.01.2012, 07:26
  • 3
    , Что команда не будет работать, если устройство составит более чем 2 ТБ –  LVLAaron 14.01.2012, 15:26
  • 4
    @AaronJAnderson я создал использование объема на 3.5 ТБ reiserfs и ext3 таким образом, если ext4 требования иметь максимальный размер объема 16 эксабайт, я не вижу оснований, что 22 ТБ не будут работать. –  Karlson 14.01.2012, 22:04
  • 5
    версия e2fsutils, который поставляет w/эта версия Linux (и большинство других в данный момент не поддерживают более чем 16 ТБ), –  LVLAaron 17.01.2012, 10:00

Для вашей таблицы разделов, как уже упоминалось, GPT является отличным вариантом, так как он поддерживает разделы до 9. 4 ZiB размером (9.4 × 1021 байт), что значительно превосходит все, что вам нужно с 22 ТБ.

Для вашей файловой системы в Linux BTRFS является отличной файловой системой копирования на запись:

  1. Его атрибут копирования на запись означает, что дважды не хранится дубликат файла.
  2. Он имеет функцию сжатия на лету, поэтому ваши данные перед записью на диск и чтением с него прогоняются через LZO или GZip, что экономит физическое дисковое пространство.
  3. Поддерживается избыточность в конфигурациях RAID-1, RAID-10, RAID-5 и RAID-6 без накладных расходов.
  4. Также поддерживается RAID-0, если речь идет о скорости.
  5. Также поддерживаются субтомные тома, моментальные снимки и многое другое.
  6. Почти все задачи файловой системы выполняются в режиме онлайн , так что вам обычно не придется размонтировать файловую систему, чтобы что-то исправить.

По своим возможностям она похожа на ZFS, но является частью основного ядра Linux.

3
27.01.2020, 19:37

Теги

Похожие вопросы