Получить гигабайты из вывода команды «free -m» (корректную устанволенную память)

free -g ?

Он округляет в меньшую сторону. Покажеь 252 вместо 256 и т.д.

P.S. dmidecode и другие варианты использовать нельзя. Заменять вывод free -m на что-то другое тоже.

Почему? Потому что я использую grains в salt-stack. И вводить свои грейнсы нежелательно.

Дели, бери двоичный логарифм, округляй до целого, возвращай значение. Изи же. Или в змеюке нет двоичного логарифма?

на некоторых серверах установлено 3 гигабайта (3072). Логарифм двоинчый не сработает.

Тут главное не перепутать гибибайты и гигабайты. В недавней версии ключики изменили и -g может показать не то что ожидаешь.

free -g

гигабайтов

man free

Нельзя использовать free -g. Можно только free -m. Это грйенсы salt, чтобы получить результат free -g, надо вводить доп. грейнсы, что нежелательно.

Тогда объясни, по какому именно правилу округляешь. Почему 3Гб — валидно, а 252Гб — нет? Если только или степени 2, или ровно 3Гб, то ну ты понял, где ветвить и выпадать.

ага. я тебя понял, спасибо. Это невозможно.

У тебя странная логика округления, но выглядит так словно тебе нужно построить отрезки где концами будут числа до которых округлять (например 2048 и 3072) и смотреть на какой отрезок попал размер памяти и по смещению от центра определять в какую сторону округлять.

Конечно можно было бы без таких костылей, но у тебя есть правила вида

251.7822265625 — надо округлить до 256, а не до 252.

$ free -g --si
              total        used        free      shared  buff/cache   available
Mem:             15           2           7           0           5          12
Swap:             4           0           4

а в системе 16 )

Попробуй это

memory = 257825
nextPowerOfTwo = pow(2, math.ceil(math.log(memory,2)))
print(nexPowerOfTwo/1024) # 256

Тут можно поправочку, но не проверял. Берешь логарифм. Берешь целую часть (не округляешь). Делишь на степень этой целой части. Его округляешь. =Результат * 2^целое.

Логарифмы, экспоненты... Я тут подумал и мы решили, что это очень легко делается битовыми операциями.

и получаем 4 вместо 3:

>>> pow(2, math.ceil(math.log(3007,2)))/1024
4.0

Потому что я использую grains в salt-stack

Нафиг оно тебе надо?

Нельзя использовать free -g. Можно только free -m.

Значит костыль лепи

Потому что скрипт уже используется пару лет и перетаскивать всё с salt на что-то другое нежелательно.

Необходимо округлить их до гигабайтов.

Ты объясни логику округления. Почему 252GB можно округлить до 256GB накинув 4GB. А 3GB до 4GB округлить нельзя? Вот возьмем 130GB, по твоей логике надо до 128GB округлять или до 256GB? Я что-то вообще логики не вижу.

Он не сможет объяснить. А логика, скорее всего, следующая: оставить N первых страших бит и двоично округлить оставшуюся часть. Осталось узнать чему равно N, но он не признается.

Захардкодить халяльные значения и округлять до них уже предлагали? Хотя ересь конечно

Вверх обычно округляется от 0.5. Обычная логика же, ему надо floor, значит 130 округляем до 4.

Построй себе дерево ифов, если очень надо, для кейсов меньше 8 вверх, больше вниз. (мне нравится как ты 15699 собираешься до 8 округлить)

Вангую что ТС хочет получить суммарный номинальный объём установленных плашек, но отчаянно не хочет получать его суммированием номинальных объёмов плашек

Жесть я расписал. N - это точность (количество бит) мантисы. А число надо предстваить в экспоненцальной форме, ественно в двоичной.

Шел писать комментарий про dmidecode, а ТС сразу обломал.

а в системе 16 )

На самом деле нет.

Вообще-то free -m в колонке Total не показывает суммарный объем планок, а странное значение, которое исключает, по-видимому, некоторое количество адресов зарезервированных биосом и устройствами. Так что как ни округляй, «правильного» объема планок не получишь

Это как-раз не проблема, зажатая ядром память много меньше суммарного её объёма

Натренируй нейросеточку :).

Я слишком тупой для этого.