У нас работает четыре хоста ESXi 6.5.0 VMware, управляемый веб-клиент vie vSphere.
Недавно я добавил в наше хранилище новый том VMFS 6, изначально созданный с емкостью 2 ТБ, но быстро увеличенный до 3 ТБ, прежде чем фактически запустить его в производство. С тех пор я не получаю постоянных показаний емкости для объема. Например: в гостевой системе изначально был диск размером 1700 ГБ на другом томе; Я перенес это на новый том, а после пытаюсь увеличить. Таким образом, в настройках изменения диск был показан как 1700 ГБ и максимальный размер 2,77 ТБ - но когда я попытался установить его на 2000 ГБ, я получил сигнал тревоги «Недостаточная емкость диска», и - о чудо - максимальный размер снизился до 1,86 ТБ! При этом мне удалось увеличить свои 1700 до 1900 ГБ только ...
При проверке информации о томе в разделе «настроить» - «общий» - «емкость» иногда отображается 1,86 ТБ как емкость (и выделенная), но иногда без каких-либо особых событий между ними отображается 2,77 ТБ (с выделенным 1,86 ТБ). Иногда, когда отображается меньшая емкость, нажатие «обновить емкость» ничего не меняет.
В разделе "Поддержка устройства" он показывает 2,77 ТБ (насколько я могу судить без колебаний?).
В разделе «монитор» - «производительность» - «обзор» я иногда вижу 2,77, а иногда и 1,86 ТБ.
И так далее ...
Каждый из четырех хостов правильно показывает объем: LUN 10 = 2,77 ТБ.
Как ни странно, журнал событий для тома показывает несколько записей «Емкость ... увеличена с 2047894093824 байтов до 3047816167424 байтов». В частности, у меня есть событие «том создан» в 05.07.2019 11:44:16 и эти события «увеличение емкости» в 2019-07-05 13:33:44, 2019-07-05 13:37: 04, 2019-07-05 15:23:28, 2019-07-05 15:53:40, 2019-07-05 16:23:41, 2019-07-05 17:19:30, 2019-07- 10 07:58:05, 2019-07-10 09:58:01. Это в восемь раз больше, чем, например, один раз на хост, и в основном (но не полностью) коррелирует со временем, когда у меня открыта vsphere, что в целом не совсем объяснимо для меня.
Вопросы:
У меня есть несколько идей, но я не могу подтвердить, действительно ли они то, что вы видите:
zfs list -o space чтобы точно показать, что используется для чего, возможно, у VMFS есть аналогичный вариант?Вот страница википедии VMFS для справки, обратите внимание, что у нее есть множество ограничений, особенно в более старых версиях, которые могут иметь отношение к вашему варианту использования. https://en.wikipedia.org/wiki/VMware_VMFS
Надеюсь это поможет!
Может ваш сервер подкачивает память на диск? У Vmware есть возможность отключить это: https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-C0DBB2A3-4B44-45BE-927E-10EEB2EB8CBE.html
Нет никаких вариаций.
Это зависит от того, как пространство интерпретируется: как поддельное пространство в базе 10 или как истинное пространство в базе 2. Производители жестких дисков перечисляют пространство в поддельном пространстве, в базе 10 и аналогичным образом некоторые программы читают его.
Что это означает для вас: на самом деле ваш фальшивый том размером 3 ТБ имеет 3 000 000 000 000 Б, что в истинном двоичном пространстве означает 2,72 ТБ. Если вы хотите настоящие 3 ТБ, вам нужно будет сделать том размером 3 221 225 472 000 Б.
Аналогичным образом, емкость base 10 емкостью 2 ТБ на самом деле будет иметь 1,81 ТБ.
Ваш объем 2047894093824 Б меньше 2 ТБ. Лучше всего это будет 2 000 000 000 КБ, что составляет 1,86 ТБ. Если вы хотите 2 ТБ, сделайте его 2199023255552 Б (или 2200000000000, если вам так удобнее).
Ваше выделение 1700 ГБ в ТБ имеет размер 1,66 ТБ. 1900G - это 1,8555 ТБ, поэтому он работал.
Чтобы устранить путаницу, некоторое время назад было официально предложено указывать бинарные истинные значения в KiB / MiB / GiB / TiB, а 10-базовые - со старыми именами, но многие не согласились с такой реализацией именования.
Поэтому, если вы создаете тома, убедитесь, что вы принимаете во внимание двоичные значения, а не их перевод на 10 оснований.
Если вы создаете том объемом 2048 ГБ, у него фактически будет ровно 2 ТБ, если указанное вами значение ГБ находится в двоичном формате, и все равно будет меньше, если это не так.