yurius |
|
Темы:
79
Сообщения:
886
Участник с: 01 января 2018
|
Возжелал узнать точный размер рут-раздела (/dev/sda1) в байтах. Он в районе 30 Гб, но захотелось узнать до байта. Так вот, df выдало
, то есть 31572529152 - это в байтах, специально ввёл переменную BLOCKSIZE=1B. Однако, когда ввёл cat /proc/partitions, выдало
И вот что это за последнее число? Вроде должно быть в килобайтах - во всяком случае в Андроиде именно так. Если его умножить на 1024, получится 32212254720, что, хотя и близко, но всё же не совпадает с 31572529152, выданным df. Отсюда два вопроса: 1) Почему имеет место несоответствие? 2) "Кому верить" - df или /proc/partitions? |
vinc |
|
Темы:
12
Сообщения:
180
Участник с: 13 июня 2015
|
yurius
fdisk (и /proc/partitions) - информация о разделе (то, что вы спросили); df - информация о конкретной файловой системе на этом разделе (под данные разные системы могут выделять разные размеры, как я понимаю). |
yurius |
|
Темы:
79
Сообщения:
886
Участник с: 01 января 2018
|
vinc Примерно понял. То есть истинный размер всего физического раздела выдаёт /proc/partitions ? И, получается, df всегда будет меньше, чем /proc/partitions? А что же это тогда за разность между ними, что лежит в разделе, но вне поля зрения df? |
vinc |
|
Темы:
12
Сообщения:
180
Участник с: 13 июня 2015
|
yuriusdf возвращает размер, доступный для хранения данных в этой файловой системе. Но сама файловая система хранит не только данные, но и служебную информацию (таблицы размещения файлов, журналы и т.д.) - вот этим и объясняется разность (как я понимаю!). PS. Какая конкретно информация относится к служебной, а какая к данным, я не уверен. Если интересно, почитайте, как устроены разные файловые системы. |
yurius |
|
Темы:
79
Сообщения:
886
Участник с: 01 января 2018
|
vincНу примерно так я и подумал. Благодарю за ответ. |
vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
yuriusНикакого несоотвествия нет, оба варианта показывают правильно, только в разных единицах измерения 32212254720 - байты 31457280 - килобайты ... 31457280 * 1024 = 32212254720 байт UPD - 32212254720/1024 = 31457280 Kb / 1024 = 30720 Mb / 1024 = 30 Gb
Ошибки не исчезают с опытом - они просто умнеют
|
yurius |
|
Темы:
79
Сообщения:
886
Участник с: 01 января 2018
|
vasekВы не то сравнили. Сравните вывод df = 31572529152 байт, и вывод /proc/partitions = 31457280 килобайт = 32212254720 байт |
vinc |
|
Темы:
12
Сообщения:
180
Участник с: 13 июня 2015
|
vasekСпорное заявление. При разбивке? Пять процентов? Например, на моих дисках разность составляет около 2% от размера раздела ext4. Вот команды с ключами, с которыми ничего не надо пересчитывать: Информация о разделе с выводом в байтах Информация о ФС в байтах Как я понимаю данный вопрос:При разбивке на разделы ничего не резервируется, просто создается таблица разделов. fdisk и lsblk показывают физический размер раздела, как он есть. А вот при форматировании (т.е. при установке файловой системы на раздел) определенное пространство раздела отводится под служебные данные этой ФС. И утилита df показывает тот размер, который может использоваться для записи пользовательских данных в этой файловой системе на этом разделе. Если я заблуждаюсь, то просьба кинуть ссылку "на почитать" для общего развития. |
yurius |
|
Темы:
79
Сообщения:
886
Участник с: 01 января 2018
|
vincДа как раз всё верно - я так понимаю, inode как раз из серии таких "метаданных". |
vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
Как это понимаю я, возможно и не совсем точно, но попробую описать. Самый правильный результат показывает fdisk (как отметил vinc физический объем) # fdisk -l /dev/sda3 И видим объем sda3 75458718720 байт (147380310*512=75458718720)Далее, в файле /proc/partitions отображены все подключенные к системе разделы жестких дисков и других запоминающих устройств, и эти значения, в принципе, должны совпадать с значениями показанными fdisk. Смотрим cat /proc/partitions | grep sda3 73690155 sda3 переводим в byte - 73690155*1024=75458718720 - совпадает с выводом fdisk, что и ожидалось. В части df, смотрим man df (лишнее убрал) И как видим, df отображает не то, что показывает fdisk и /proc/partitions, то есть он не показывает полный объем раздела (точнее физический объем), а показывает только тот объем, который относится к файловой системе (грубо говоря, тот объем, который будут занимать файлы, т. е. сами данные, без учета другой информации …… о чем писал vinc). Смотримdf -B 1 /dev/sda3 Файловая система 1B-блоков Использовано Доступно /dev/sda3 73736003584 22558220288 47388073984 Из этого же вывода можно определить какой объем системой при разбивке диска/раздела резервируется под нужды root-пользователя (по дефолту примерно пять процентов), смотрим 73736003584 - 22558842880 - 47387451392 = 3789709312 3789709312/73736003584 *100=5,14% UPD - процент резервирования можно изменить, если мне не изменяет память, используя утилиту tune2fs Как то так - повторюсь, возможно в чем то я и не совсем прав, но это близко к реалиям.
Ошибки не исчезают с опытом - они просто умнеют
|