Как видеть, что пространство использовало/освобождало от каждого PV в LVM

Вы не можете сделать fdisk, потому что вы уже имеете максимум в два раза больше MBR с устройством объемом 4 ТБ на секторах 512b. Вам необходимо отформатировать его с помощью GPT.

Из википедии:

Организация таблицы разделов в MBR ограничивает максимальное адресуемое пространство диска 2 ТБ (232 × 512 байт).

Получите пакет gdisk и переформатируйте диск (хотя мне кажется, что так уже и должно быть). Если вы смотрите на этот диск с машины, которая не может смонтировать GPT диск, то защитный MBR будет объяснять искаженный hdparm.

Иначе я вижу, что размер физического сектора указан на 4 кб - что немного логичнее - и делает MBR выполнимой, но, как вы видели, довольно громоздкой. Решение будет лежать в обновленной таблице разделов.

Больше информации из Википедии

Так как информация о разделах хранится в таблице разделов MBR с использованием адреса начального блока и длины, теоретически возможно определить разделы таким образом, чтобы выделенное пространство для диска с 512-байтными секторами давало суммарный размер, приближающийся к 4 ТБ, если все разделы, кроме одного, расположены ниже предела в 2 ТБ, а последний назначается как начинающийся с блока 232-1 или близкий к нему и задает размер до 232-1, определяя, таким образом, раздел, который требует 33, а не 32 бита для доступа к адресу сектора. Однако, на практике это поддерживается только определенными операционными системами с поддержкой LBA-48, включая Linux, FreeBSD и Windows 7, которые используют 64-битные адреса секторов внутри организации.

Из-за ограничений на пространство кода и природы таблицы разделов MBR, поддерживающей только 32 бита, загрузочные сектора, даже если включена поддержка LBA-48, а не LBA-28, часто используют 32-битные вычисления, если только они специально не предназначены для поддержки всего диапазона адресов LBA-48 или предназначены только для работы на 64-битных платформах. Любой загрузочный код или операционная система, использующая внутренние адреса 32-битных секторов, приведет к тому, что адреса будут обернуты вокруг доступа к этому разделу и, таким образом, к серьезному повреждению данных на всех разделах.

Для дисков, имеющих размер сектора, отличный от 512 байт, например, USB-внешние диски, также существуют ограничения. Размер сектора 4096 приводит к восьмикратному увеличению размера раздела, который можно определить с помощью MBR, позволяя создавать разделы размером до 16 ТБ (232 × 4096 байт). Версии Windows более свежие, чем Windows XP, поддерживают больший размер секторов, а также Mac OS X, а ядро Linux поддерживает больший размер секторов начиная с 2.6.31 или 2.6.32, но проблемы с загрузчиками, утилитами разметки и реализацией BIOS компьютера имеют определенные ограничения, так как они часто жестко связаны, чтобы зарезервировать только 512 байт для буферов секторов, что приводит к тому, что память перезаписывается для секторов большего размера . Это также может привести к непредсказуемому поведению, и поэтому его следует избегать, когда речь идет о совместимости и соответствии стандартам.

Там есть ссылка на Western Digital .pdf, где обсуждается возможность использования больших размеров секторов MBR на очень больших дисках. Очевидно, что ядро версии 2.6.32 первым в мире ввело поддержку этой возможности. Я не знаю, является ли она опцией времени компиляции или нет, но, возможно, она была слишком новой, когда было собрано собственное ядро NAS.

Очевидно, есть и другие возможности. Из .pdf

Older Linux Kernel version (all 2.4 and pre‐2.6.32) computing 
environments with a legacy BIOS and MBR partition table scheme 
encounter a barrier at 2.19 TB because they can address only up 
to 232 logical blocks. Be sure to use kernels that contain support 
for drives greater than 2.19TB.  The kernels released after April 
2010 have support for large capacity drives using 4096 sector sizes.

...

How You Can Take Advantage of Large Capacity Drives in Linux
• Use fdisk from util‐linux‐ng >= 2.17.2 or parted/gparted   
• Use +size {M, G} convention to specify "Last sector" 
  (e.g. +5G to create 5GiB partition) then fdiskl aligns the 
  size to physical block boundary  
• Remember that fdisk(8) always follows your wishes ‐‐ it means 
  that if you explicitly define first/last sector number then 
  the partition could be misaligned.
• Start the extended partition at sector 64 (the default is 63), 
  and end it at sector (total amount of sectors on the drive – 1)

1
20.10.2014, 21:54
1 ответ

Это на самом деле не возможно; LVM ничего не знает о файлах.

LVM создает логические тома, которые являются блочными устройствами. Они функционируют многое, как другое другое другое блок-устройство, такое как жесткий диск, и, таким образом, они не знают или не позаботятся о том, что данные хранятся на них. К LVM, его просто серия 0s и 1s, организованной в блоках X-Byte.

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

Так же, как вы не сможете задать ваш жесткий диск, который питает файлы, вы не можете задать LVM, которые PVS содержат файлы.

[Вы, конечно, могли пройти каждый файл в файловой системе, попросить файловую систему, которая блокирует ее хранить, затем задать LVM, где каждый из этих блоков есть, и поместить все вместе, но я не в курсе любого инструмента для этого. И не я уверен, что вы хотите , чтобы сделать это.]

2
27.01.2020, 23:37

Теги

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