Несоответствие между /proc/partitions и df

Возжелал узнать точный размер рут-раздела (/dev/sda1) в байтах. Он в районе 30 Гб, но захотелось узнать до байта. Так вот, df выдало

/dev/sda1        31572529152  12683735040  17261404160  43% /

, то есть 31572529152 - это в байтах, специально ввёл переменную BLOCKSIZE=1B. Однако, когда ввёл cat /proc/partitions, выдало

8        1   31457280 sda1

И вот что это за последнее число? Вроде должно быть в килобайтах - во всяком случае в Андроиде именно так. Если его умножить на 1024, получится 32212254720, что, хотя и близко, но всё же не совпадает с 31572529152, выданным df. Отсюда два вопроса:

1) Почему имеет место несоответствие?
2) "Кому верить" - df или /proc/partitions?
yurius
Возжелал узнать точный размер рут-раздела (/dev/sda1) в байтах.
sudo fdisk -l /dev/sda1

fdisk (и /proc/partitions) - информация о разделе (то, что вы спросили);
df - информация о конкретной файловой системе на этом разделе (под данные разные системы могут выделять разные размеры, как я понимаю).
vinc
fdisk (и /proc/partitions) - информация о разделе (то, что вы спросили);
df - информация о конкретной файловой системе на этом разделе (под данные разные системы могут выделять разные размеры, как я понимаю).

Примерно понял. То есть истинный размер всего физического раздела выдаёт /proc/partitions ? И, получается, df всегда будет меньше, чем /proc/partitions? А что же это тогда за разность между ними, что лежит в разделе, но вне поля зрения df?
yurius
А что же это тогда за разность между ними, что лежит в разделе, но вне поля зрения df?
df возвращает размер, доступный для хранения данных в этой файловой системе.
Но сама файловая система хранит не только данные, но и служебную информацию (таблицы размещения файлов, журналы и т.д.) - вот этим и объясняется разность (как я понимаю!).
PS. Какая конкретно информация относится к служебной, а какая к данным, я не уверен. Если интересно, почитайте, как устроены разные файловые системы.
vinc
но и служебную информацию (таблицы размещения файлов, журналы и т.д.)
Ну примерно так я и подумал. Благодарю за ответ.
yurius
1) Почему имеет место несоответствие?
2) "Кому верить" - df или /proc/partitions?
Никакого несоотвествия нет, оба варианта показывают правильно, только в разных единицах измерения
32212254720 - байты
31457280 - килобайты ... 31457280 * 1024 = 32212254720 байт
UPD - 32212254720/1024 = 31457280 Kb / 1024 = 30720 Mb / 1024 = 30 Gb
Ошибки не исчезают с опытом - они просто умнеют
vasek
32212254720 - байты
31457280 - килобайты … 31457280 * 1024 = 32212254720 байт
Вы не то сравнили. Сравните вывод df = 31572529152 байт, и вывод /proc/partitions = 31457280 килобайт = 32212254720 байт
vasek
Linux при разбивке диска резервирует под нужды root-пользователя пять процентов раздела
Спорное заявление.
При разбивке? Пять процентов?
Например, на моих дисках разность составляет около 2% от размера раздела ext4.

Вот команды с ключами, с которыми ничего не надо пересчитывать:
Информация о разделе с выводом в байтах
sudo fdisk -l /dev/sda1
или
lsblk -b /dev/sda1
Информация о ФС в байтах
df --block-size=1 /dev/sda1
Как я понимаю данный вопрос:
При разбивке на разделы ничего не резервируется, просто создается таблица разделов.
fdisk и lsblk показывают физический размер раздела, как он есть.
А вот при форматировании (т.е. при установке файловой системы на раздел) определенное пространство раздела отводится под служебные данные этой ФС. И утилита df показывает тот размер, который может использоваться для записи пользовательских данных в этой файловой системе на этом разделе.
Если я заблуждаюсь, то просьба кинуть ссылку "на почитать" для общего развития.
vinc
Если я заблуждаюсь
Да как раз всё верно - я так понимаю, inode как раз из серии таких "метаданных".
Как это понимаю я, возможно и не совсем точно, но попробую описать.

Самый правильный результат показывает fdisk (как отметил vinc физический объем)
# fdisk -l /dev/sda3
Диск /dev/sda3: 70,3 GiB, 75458718720 байт, 147380310 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
И видим объем sda3 75458718720 байт (147380310*512=75458718720)
Далее, в файле /proc/partitions отображены все подключенные к системе разделы жестких дисков и других запоминающих устройств, и эти значения, в принципе, должны совпадать с значениями показанными fdisk. Смотрим
cat /proc/partitions | grep sda3
73690155 sda3
переводим в byte - 73690155*1024=75458718720 - совпадает с выводом fdisk, что и ожидалось.

В части df, смотрим man df (лишнее убрал)
df displays the amount of disk space available on the file system containing each file name argument.
If an argument is the absolute file name of a disk device node containing a  mounted  file  system,  df shows  the  space  available  on  that file system rather than on the file system containing the device node.
И как видим, 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

Как то так - повторюсь, возможно в чем то я и не совсем прав, но это близко к реалиям.
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.