Disk Usage Analyzer и df

Как правильно задавать вопросы Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Для начала воспользуйтесь поиском форума. 2. Укажите версию ОС вместе с разрядностью. Пример: LM 19.3 x64, LM Sarah x32 3. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 4. Какое железо. (достаточно вывод inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот
Аватара пользователя

Автор темы
madesta
Сообщения: 1989
Зарегистрирован: 11 июн 2017, 21:47
Решено: 28
Откуда: BY
Благодарил (а): 79 раз
Поблагодарили: 425 раз
Контактная информация:

Disk Usage Analyzer и df

#1

30 май 2019, 18:57

Имела место неожиданная ситуация, связанная с нехваткой свободного дискового пространства для записи большого массива данных на примонтированный раздел. При этом проведённая перед операцией записи проверка через Disk Usage Analyzer не показала, что свободного места не хватает.

Произведенное позднее сравнение показаний Disk Usage Analyzer и самопального скрипта, использующего df, выявило различие в результатах.

Скрипт df.sh:
#!/bin/bash
echo ""
echo ""
echo -e "\E[33m\tПодсчёт свободного и занятого места на дисках\n"
sleep 1
echo -e "\E[36m\tОзнакомьтесь с результатами подсчёта:\n\n"
echo -en "\E[0m"
sleep 1; df -h /dev/sda1
echo ""
echo -en "\E[0m"
sleep 1; df -h /dev/sdb1
echo ""
echo ""
sleep 3
echo -e "\E[32m\tАвтозакрытие окна произойдёт через 10 секунд.\n\n"
sleep 10; exit

Показания Disk Usage Analyzer:

duu1.png
duu1.png (4.26 КБ) 1206 просмотров
результат для sda1
duu2.png
duu2.png (3.83 КБ) 1206 просмотров
результат для sdb1


Показания df.sh:
duu3.png

Выходит, что Disk Usage Analyzer врёт, а df.sh говорит правду? Или используются разные методики подсчёта?

Может кто-нибудь из опытных товарищей сможет прояснить ситуацию?

Точкой монтирования sdb1 на sda1 является каталог /home/minter/N-2. Монтирование осуществляется при загрузке. Соответствующая строка fstab:

UUID=b72b0384-9782-4eaf-9606-ca48469ef6da /home/minter/N-2 ext4 rw 0 0

После формулирования данного вопроса пришла идея проверить показания емкостей накопителей на соответствие кратности 1,024 Показания оказались кратны. Дальше проверять не стал, так как не понятно: учитывает ли Disk Usage Analyzer резервируемые по умолчанию 5 % размера файловой системы под нужды root для перестройки индексов при её "ремонте".

Так и хочется авторов подобной путаницы лишить наиболее ценной части организма, потому что в переводе на рабоче-крестьянский язык получается, что деньги заплачены за килограмм сметаны, а на руки выдали грамм так 900-950.

Аватара пользователя

slant
Сообщения: 4469
Зарегистрирован: 21 июн 2017, 18:09
Решено: 95
Благодарил (а): 51 раз
Поблагодарили: 1966 раз
Контактная информация:

Disk Usage Analyzer и df

#2

30 май 2019, 21:09

madesta писал(а):
30 май 2019, 18:57
Так и хочется авторов подобной путаницы лишить наиболее ценной части организма, потому что в переводе на рабоче-крестьянский язык получается, что деньги заплачены за килограмм сметаны, а на руки выдали грамм так 900-950.
Читайте про то, что такое "кластер" на диске, и почему куча мелких файлов, номинально - с тем же количеством байт, фактически займут больше места, чем один большой файл с тем же количеством байт. Такое происходит в большинстве файловых систем. В том числе и в ext4.

Кластер (единица хранения данных)

Аватара пользователя

Whowka
Сообщения: 1899
Зарегистрирован: 20 июл 2018, 19:50
Решено: 13
Откуда: Питер
Благодарил (а): 777 раз
Поблагодарили: 948 раз

Disk Usage Analyzer и df

#3

30 май 2019, 22:04

slant писал(а):
30 май 2019, 21:09
куча мелких файлов
Исходя из:
duu3.png
duu3.png (22.56 КБ) 1180 просмотров
1.8 - 1.6= 200G, но показывает тока 29G Это так может разрастись фсякая мелочь?(я ,просто, для себя хочу понять: возможно ли такое?)

no avatar

Griga211
Сообщения: 405
Зарегистрирован: 01 окт 2016, 15:20
Решено: 2
Благодарил (а): 9 раз
Поблагодарили: 62 раза
Контактная информация:

Disk Usage Analyzer и df

#4

30 май 2019, 22:07

Покажи fdisk -l

Аватара пользователя

slant
Сообщения: 4469
Зарегистрирован: 21 июн 2017, 18:09
Решено: 95
Благодарил (а): 51 раз
Поблагодарили: 1966 раз
Контактная информация:

Disk Usage Analyzer и df

#5

31 май 2019, 00:03

Whowka писал(а):
30 май 2019, 22:04
Это так может разрастись фсякая мелочь?(я ,просто, для себя хочу понять: возможно ли такое?)
Ситуативно.

Допустим, размер кластера - 512 байт. Значит, это минимальный фактический размер файла. Т.е. если у нас 200000 файлов (что только кажется большим числом а реально встречается достаточно часто на практике) - это минимум 200000 * 512байт = ~97 мегабайт, даже если в каждом из этих файлов всего один символ, т.е. 1 байт. Плюс - метаданные файловой системы, плюс ее журнал.

Однако идем в вики, и смотрим там, какой же размер кластера (точнее в терминологии ext4 - логического блока, т.к. для нее кластером называется несколько иное) используется в ext4 чаще всего. Ответ - 4кб. Т.е. накладные расходы выше умножаем на 8. А это уже ~781мб.

Что касается количества файлов - вот у меня просто каталог с играми, прямо сейчас посмотрел: ~187000 файлов, 92Гб.

Аватара пользователя

vir0id
Сообщения: 2757
Зарегистрирован: 19 дек 2017, 18:48
Решено: 15
Откуда: Рига
Благодарил (а): 163 раза
Поблагодарили: 305 раз
Контактная информация:

Disk Usage Analyzer и df

#6

31 май 2019, 04:14

Ну... Вообще-то, все вот это вот - удивительно. Хотя и не без своей логики, наверное. По факту, параметр -h показывает человеческий вывод, но где он там человеческий?
slant писал(а):
31 май 2019, 00:03
Допустим, размер кластера - 512 байт
Вот я представляю как сидит какой-нибудь пользователь и всегда помнит, что размер клайстера 512 байт. При необходимости включает в своей башке инженерный калькулятор и производит подсчет всех файлов на клайстер.
И сказала Сара Конор
- Да пошло все нахрен!
И сделала аборт

Аватара пользователя

slant
Сообщения: 4469
Зарегистрирован: 21 июн 2017, 18:09
Решено: 95
Благодарил (а): 51 раз
Поблагодарили: 1966 раз
Контактная информация:

Disk Usage Analyzer и df

#7

31 май 2019, 11:43

А "обычному пользователю" достаточно запомнить, что свободное место - это параметр вида "предположительно". Как будет по факту - зависит от того, чем это место забивать будешь.

С учетом того, что для практически любой FS надо хотя-бы 15-20% свободного места чтобы хорошо себя чувствовать и не тормозить от растущей фрагментации - оно в общем-то и не особо актуально обычно.

no avatar

Griga211
Сообщения: 405
Зарегистрирован: 01 окт 2016, 15:20
Решено: 2
Благодарил (а): 9 раз
Поблагодарили: 62 раза
Контактная информация:

Disk Usage Analyzer и df

#8

31 май 2019, 12:50

slant писал(а):
31 май 2019, 11:43
А "обычному пользователю" достаточно запомнить, что свободное место - это параметр вида "предположительно"..
Обычному пользователю достаточно понимать в каких единицах показывает размер конкретное ПО - ГБ или ГиБ. Машина всегда будет использовать только ГиБ. И то что какое то ПО отображает информацию в ГБ, это уже не проблема машины и железа. Это проблема уже самого пользователя - используй "нормальное" ПО.
Что касается секторов - машина пишет по секторам, это естественно. Сколько она в него запишет байт - неважно, если запись была, то сектор считается израсходованным. Она в него уже писать не будет и считать оставшееся место в нем она не будет. Она всегда будет считать только сектора, которые помечены как свободные. Поэтому, размер сколько ещё можно записать на диск это размер в ГиБ.
Не знаю какую там кратность считал автор, но он считал что то мифическое. Одинаковое количество свободных секторов в любой программе в одинаковых единицах будет всегда одинаково, потому что этим делом занимается контроллер диска. Он не может предоставлять разную информацию для разных программ. Он всегда предоставит одинаковое количество секторов. А вот как это предстанет перед пользователем - это уже зависит от конкретной программы. Поэтому те скрины что он привел отображают достоверную информацию, но в разных единицах. Там где общий размер указан как 2 - программа считает кратно 1000, т.е. КБ, МБ, ГБ, а вот там где указано общий размер 1,8 - программа считает кратно 1024, т.е. КиБ, МиБ, ГиБ. Это те цифры которые отображают реальность, это то сколько данных влезет на диск при естественном использовании. При учёте свободного места надо ориентироваться именно на КиБ, МиБ, ГиБ, ибо так считает сама машина.
Показательным примером про сектора будет тот факт, что в окошках раньше можно было узнать 2 размера файла. Первая цифра показывала его размер без учёта секторов, а вторая размер с учётом того сколько он секторов занимает на диске.

Аватара пользователя

Автор темы
madesta
Сообщения: 1989
Зарегистрирован: 11 июн 2017, 21:47
Решено: 28
Откуда: BY
Благодарил (а): 79 раз
Поблагодарили: 425 раз
Контактная информация:

Disk Usage Analyzer и df

#9

31 май 2019, 15:53

Griga211 писал(а):
30 май 2019, 22:07
Покажи fdisk -l

Код: Выделить всё

Диск /dev/sda: 931,5 GiB, 1000204886016 байт, 1953525168 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: dos
Идентификатор диска: 0x754fdf08

Устр-во    Загрузочный начало      Конец    Секторы Размер Идентификатор Тип
/dev/sda1  *             2048 1953523711 1953521664 931,5G            83 Linux


Диск /dev/sdb: 1,8 TiB, 2000398934016 байт, 3907029168 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: gpt
Идентификатор диска: 94400139-B22A-4AB3-B7F6-37B8C4F101DF

Устр-во    начало      Конец    Секторы Размер Тип
/dev/sdb1      64 3907029134 3907029071   1,8T Microsoft basic data

Аватара пользователя

vir0id
Сообщения: 2757
Зарегистрирован: 19 дек 2017, 18:48
Решено: 15
Откуда: Рига
Благодарил (а): 163 раза
Поблагодарили: 305 раз
Контактная информация:

Disk Usage Analyzer и df

#10

31 май 2019, 16:03

Код: Выделить всё

Диск /dev/sda: 931,5 GiB
Диск /dev/sdb: 1,8 TiB
Всё тут сходится.
madesta писал(а):
30 май 2019, 18:57
Точкой монтирования sdb1 на sda1 является каталог /home/minter/N-2
Может дело всё в монтировании большего объёма к меньшему? И... возможно, slant, прав.
slant писал(а):
30 май 2019, 21:09
куча мелких файлов, номинально - с тем же количеством байт, фактически займут больше места, чем один большой файл с тем же количеством байт

Аватара пользователя

Автор темы
madesta
Сообщения: 1989
Зарегистрирован: 11 июн 2017, 21:47
Решено: 28
Откуда: BY
Благодарил (а): 79 раз
Поблагодарили: 425 раз
Контактная информация:

Disk Usage Analyzer и df

#11

31 май 2019, 16:11

Griga211 писал(а):
31 май 2019, 12:50
а вот там где указано общий размер 1,8 - программа считает кратно 1024, т.е. КиБ, МиБ, ГиБ. Это те цифры которые отображают реальность, это то сколько данных влезет на диск при естественном использовании.
Получается, что Disk Usage Analyzer показал, если так можно выразиться, голый объём данных. А df отобразил реально занимаемое место. То есть если кластер был заполнен не полностью, то он всё равно считался занятым и, соответственно, занимаемое этим кластером место тоже минусовалось из общего числа, даже если кластер был заполнен всего лишь несколькими байтами.

В итоге, ориентируясь на данные, предоставленные Disk Usage Analyzer для sdb1, сделал попытку впихнуть в него "невпихуемое". Что и показала последующая проверка df, которая выдала "не могу записать, потому что свободно 0".

Выходит, что для практической цели определения доступного для использования дискового пространства следует ориентироваться на показания df, в то время как цифровые данные Disk Usage Analyzer имеют больше теоретический аспект. Другими словами, теоретически, объём вещей для турпохода, сопоставимый с объёмом рюкзака, в рюкзак влезет, а на практике в него поместится не всё.

Я верно понял ветку обсуждения или необходимо продолжить работу над ликвидацией собственной неграмотности?
Последний раз редактировалось пользователем 2 madesta; всего редактировалось раз: 31

Аватара пользователя

rogoznik
Сообщения: 10015
Зарегистрирован: 27 июн 2017, 13:36
Решено: 128
Откуда: Нижний Тагил
Благодарил (а): 776 раз
Поблагодарили: 1950 раз
Контактная информация:

Disk Usage Analyzer и df

#12

31 май 2019, 16:14

 ! Сообщение из: darkfenix
madesta, изучить и пользоваться Панель форматирования текста в темах/ответах иначе буду карать :evil:
ИзображениеИзображение

Аватара пользователя

Автор темы
madesta
Сообщения: 1989
Зарегистрирован: 11 июн 2017, 21:47
Решено: 28
Откуда: BY
Благодарил (а): 79 раз
Поблагодарили: 425 раз
Контактная информация:

Disk Usage Analyzer и df

#13

31 май 2019, 16:21

darkfenix писал(а):
31 май 2019, 16:14
изучить и пользоваться Панель форматирования текста в темах/ответах иначе буду карать
Осознал.

Аватара пользователя

Автор темы
madesta
Сообщения: 1989
Зарегистрирован: 11 июн 2017, 21:47
Решено: 28
Откуда: BY
Благодарил (а): 79 раз
Поблагодарили: 425 раз
Контактная информация:

Disk Usage Analyzer и df

#14

31 май 2019, 17:02

slant писал(а):
31 май 2019, 11:43
С учетом того, что для практически любой FS надо хотя-бы 15-20% свободного места чтобы хорошо себя чувствовать и не тормозить от растущей фрагментации - оно в общем-то и не особо актуально обычно.
Придерживался точно такой же точки зрения, особенно ещё 10 лет назад когда сидел на Windows. После 3 лет использования Linux предпринял попытку оценить фрагментацию после всех издевательств в виде многократных записей/удаления файлов на жёстких дисках с ФС ext4 - sudo e4defrag -c /dev/sd... Велико было изумление и недоверие, когда в результатах проверки было выдано "does not need defragmentation" и "Fragmentation score = 0" (0-30 = дефрагментация не требуется, 31-55 = небольшая степень фрагментации, больше 56 = необходима дефрагментация).

Всё равно произвёл принудительную дефрагментацию. Наибольшее время (6 часов) ушло на дефрагментацию раздела, заполненного более чем на 90 %, в ходе которой система 5 раз выдавала предупреждения о 0 байт свободного места. Итогом было "Fragmented percentage: 11 % - > 5 %". Большое время дефрагментации было обусловлено тем, что почти 1,8 Тб было забито видеоконтентом с размерами файлов от 300 Мб до 2 Гб. После такого убедился, что ext4 лучше, чем ntfs, которая как никакая другая ФС подвержена фрагментации https://www.ixbt.com/storage/ntfs.html

На Windows много времени занимали очистка от временных файлов, чистка реестра, оптимизация реестра, дефрагментация дисков (было бы, вероятно, правильнее говорить разделов). Может быть излишне параноидально подходил к этому вопросу, но после каждого сеанса интенсивной работы в Windows проверки состояния дел показывали желательность осуществления таких процедур.
Последний раз редактировалось пользователем 1 madesta; всего редактировалось раз: 31

no avatar

Griga211
Сообщения: 405
Зарегистрирован: 01 окт 2016, 15:20
Решено: 2
Благодарил (а): 9 раз
Поблагодарили: 62 раза
Контактная информация:

Disk Usage Analyzer и df

#15

31 май 2019, 17:33

madesta писал(а):
31 май 2019, 16:11
Получается, что Disk Usage Analyzer показал, если так можно выразиться, голый объём данных. А df отобразил реально занимаемое место
Ну если опустить все остальное, то условно - да, DUA берет количество байт и делит их на кратность в десятичной системе 10^3=1000, но ведь данные на диске находятся в двоичном виде, следовательно и размер будет исчисляться в кратности из двоичной системы. Принято брать 2^10=1024, поэтому и получается что, чтобы узнать размер данных надо делить на 1024, т.е. на кратность из той системы, в которой хранятся данные. Поэтому правильный размер будет в той программе, которая считает кратность двоичной системы, это fdisk, du и другие.
madesta писал(а):
31 май 2019, 16:11
То есть если кластер был заполнен не полностью, то он всё равно считался занятым и, соответственно, занимаемое этим кластером место тоже минусовалось из общего числа, даже если кластер был заполнен всего лишь несколькими байтами.
Это делают обе программы, просто DUA с точки зрения хранения данных считает "не правильно". Это тоже самое если мощность двигателя считать не в общепринятых л.с., а, допустим, в ишаках.
madesta писал(а):
31 май 2019, 16:11
В итоге, ориентируясь на данные, предоставленные Disk Usage Analyzer для sdb1, сделал попытку впихнуть в него "невпихуемое"
Именно так и было
madesta писал(а):
31 май 2019, 16:11
Я верно понял ветку обсуждения или необходимо продолжить работу над ликвидацией собственной безграмотности?
Если тебе хватит той абстракции, что написали в этой теме, то можешь остановиться, если хочешь узнать почему это так и откуда пошло, то продолжи изучение вопроса.

Аватара пользователя

Chocobo
Сообщения: 10015
Зарегистрирован: 27 авг 2016, 22:57
Решено: 215
Откуда: НН
Благодарил (а): 815 раз
Поблагодарили: 3008 раз
Контактная информация:

Disk Usage Analyzer и df

#16

31 май 2019, 17:56

Griga211 писал(а):
31 май 2019, 17:33
байт и делит их на кратность в десятичной системе 10^3=1000, но ведь данные на диске находятся в двоичном виде, следовательно и размер будет исчисляться в кратности из двоичной системы. Принято брать 2^10=1024
Это конфуз для многих падаванов от ИТ, когда в килобайте внезапно осказывается 1000 байт, вместо 1024 :)
Ну и также для ознакомления - Двоичные приставки
Изображение
   
Изображение

no avatar

Griga211
Сообщения: 405
Зарегистрирован: 01 окт 2016, 15:20
Решено: 2
Благодарил (а): 9 раз
Поблагодарили: 62 раза
Контактная информация:

Disk Usage Analyzer и df

#17

31 май 2019, 17:58

madesta писал(а):
31 май 2019, 17:02
Велико было изумление и недоверие, когда в результатах проверки было выдано "does not need defragmentation" и "Fragmentation score = 0"
Все потому что у них разный подход к расположению данных на диске. В ntfs данные пишутся всегда в начало раздела и по порядку. Допустим, если записать 3 небольших файла на раздел, потом удалить 2-й, а после записать 4-й файл размером больше чем был 2-й, то в ntfs, независимо от свободного места на разделе, он начнет писаться сначала, сколько влазит, на место 2-го, а остаток уже после 3-го файла. Вуаля, имеем фрагментированный файл и так происходит постоянно.
В ext4 же все по-другому. В этой системе изначально используется все пространство раздела, а файлы размазываются по диску. Т.е., если повторить эксперимент с 3 файлами, то система сделает так: если 4-й не влазит на место 2-го, то он будет целиком записан после 3-го. Вуаля, файлы идут по порядку и целиком, фрагментации нет. Пока на разделе есть место для записи файла целиком - фрагментации не будет. Но ситуация будет постепенно меняться с уменьшением свободного места. Поэтому чтобы уменьшить это явление в ext4 достаточно просто иметь много свободного места. В ntfs такое не прокатит.
Исходя из этого у ext4 есть приятная особенность - равномерное изнашивание поверхности диска. Когда то натыкался на толковую статью на эту тему, если будет время - попробую отыскать ее.

Аватара пользователя

Chocobo
Сообщения: 10015
Зарегистрирован: 27 авг 2016, 22:57
Решено: 215
Откуда: НН
Благодарил (а): 815 раз
Поблагодарили: 3008 раз
Контактная информация:

Disk Usage Analyzer и df

#18

31 май 2019, 18:08

Griga211 писал(а):
31 май 2019, 17:33
но ведь данные на диске находятся в двоичном виде, следовательно и размер будет исчисляться в кратности из двоичной системы.
Ну и это вот не совсем верно, байтами и битами оно хранится оно хранится, а как их нам считать и в каком стандарте - это уже к разным конкретным случаям :)

Никто ж не мешает считать, например, тонны грузов гибиграммами и полученную зарплату кибирублями :-D Это не будет откровенно неправильным, просто слишком диковато :crazy:
Изображение
   
Изображение

no avatar

Griga211
Сообщения: 405
Зарегистрирован: 01 окт 2016, 15:20
Решено: 2
Благодарил (а): 9 раз
Поблагодарили: 62 раза
Контактная информация:

Disk Usage Analyzer и df

#19

31 май 2019, 18:12

Chocobo писал(а):
31 май 2019, 17:56
Это конфуз для многих падаванов от ИТ, когда в килобайте внезапно осказывается 1000 байт, вместо 1024
Путаницу еще добавляет то, что в мире Кило - это 1000 байт, а Киби - 1024, а в России просто взяли и прибили на гвозди одно к другому. Теперь у нас по закону кратность используется из двоичной системы, т.е. 1024, а приставки используются от десятичной системы))) Я вот только не знаю, можно судиться с производителями, которые указывают 2 ТБ, а на самом деле там всего 1,8?

Аватара пользователя

vir0id
Сообщения: 2757
Зарегистрирован: 19 дек 2017, 18:48
Решено: 15
Откуда: Рига
Благодарил (а): 163 раза
Поблагодарили: 305 раз
Контактная информация:

Disk Usage Analyzer и df

#20

31 май 2019, 18:21

Griga211 писал(а):
31 май 2019, 18:12
которые указывают 2 ТБ, а на самом деле там всего 1,8?
Ну во первых судиться задолбаешься. А во вторых, кто знает как твоё устройство смотрится на другом железе? Может там все 2ТБ, а может и совсем половинка.

Закрыто

Вернуться в «Системные утилиты»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 7 гостей