доступное дисковое пространство
по словам моего поставщика у меня есть два диска с 250G пространство на моем сервере Linux
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME FSTYPE SIZE MOUNTPOINT LABEL
sdb 238.5G
├─sdb2 linux_raid_member 512M rescue:1
│ └─md1 ext3 511.4M /boot
├─sdb3 linux_raid_member 222G rescue:2
│ └─md2 ext4 221.9G /
└─sdb1 linux_raid_member 16G rescue:0
└─md0 swap 16G [SWAP]
sda 238.5G
├─sda2 linux_raid_member 512M rescue:1
│ └─md1 ext3 511.4M /boot
├─sda3 linux_raid_member 222G rescue:2
│ └─md2 ext4 221.9G /
└─sda1 linux_raid_member 16G rescue:0
└─md0 swap 16G [SWAP]
root@Ubuntu-1604-xenial-64-minimal ~ # df -h
Filesystem Size Used Avail Use% Mounted on
udev 16G 0 16G 0% /dev
tmpfs 3.2G 318M 2.9G 10% /run
/dev/md2 219G 208G 0 100% /
tmpfs 16G 4.0K 16G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
tmpfs 8.0G 1.4G 6.7G 17% /opt/zammad/tmp
/dev/md1 488M 199M 264M 43% /boot
tmpfs 3.2G 0 3.2G 0% /run/user/0
Я удалил некоторые резервные копии (больше чем 21 ГБ) в /opt/zammad-db-backups
затем я добрался
root@Ubuntu-1604-xenial-64-minimal /opt/zammad-db-backups # df -h
Filesystem Size Used Avail Use% Mounted on
udev 16G 0 16G 0% /dev
tmpfs 3.2G 318M 2.9G 10% /run
/dev/md2 219G 207G 715M 100% /
tmpfs 16G 4.0K 16G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
tmpfs 8.0G 1.4G 6.7G 17% /opt/zammad/tmp
/dev/md1 488M 199M 264M 43% /boot
tmpfs 3.2G 0 3.2G 0% /run/user/0
Почему я добрался только 715M в '/'? где остальная часть> 21 ГБ?
и почему я добираюсь только
du / -sh
du: cannot access '/proc/21051/task/21051/fd/4': No such file or directory
du: cannot access '/proc/21051/task/21051/fdinfo/4': No such file or directory
du: cannot access '/proc/21051/fd/3': No such file or directory
du: cannot access '/proc/21051/fdinfo/3': No such file or directory
85G /
85G используемый, когда команда df говорит мне корневую точку монтирования, у меня есть 100% 219G используемый
Система набега использует остальных для обеспечения избыточных данных? Диск на 250 ГБ и я можем примерно использовать 85 ГБ (плюс остальная часть разделов хорошо, но тем не менее это к очень(?)),
Вывод df-i
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 4092629 461 4092168 1% /dev
tmpfs 4099946 1691 4098255 1% /run
/dev/md2 14540800 3453478 11087322 24% /
tmpfs 4099946 2 4099944 1% /dev/shm
tmpfs 4099946 4 4099942 1% /run/lock
tmpfs 4099946 17 4099929 1% /sys/fs/cgroup
tmpfs 4099946 334275 3765671 9% /opt/zammad/tmp
/dev/md1 131072 308 130764 1% /boot
tmpfs 4099946 4 4099942 1% /run/user/0
1 ответ
то, когда у Вас есть раздел некоторого размера, затем форматирующего его, могло бы a) отбросить некоторые неприменимые части в конце раздела из-за гранулярности файловой системы и b) израсходовать некоторое пространство для управления данными этот новый объем включая журналирование (катастрофический отказ приводят безопасную функцию к сбою), и подобные вещи (как методы сокращения износа). это естественно и характерно для выбранной файловой системы. при выборе (или разработке) другая файловая система может изменить это. иногда существуют параметры конфигурации к файловой системе во время создания, которое может изменить это место потребления памяти также. некоторые файловые системы могли бы даже смочь реконфигурировать существующий объем.
когда Ваша система работает, у Вас могли бы быть запущенные приложения, которые израсходовали некоторое пространство, выпустили его снова, но еще не закрыли те файлы (через их дескрипторы файлов). могли бы быть дальнейшие аспекты в этом объеме, например, обработка особого случая для жестких ссылок. заключительные приложения выборочно могли бы освободить и таким образом представить инициатора. просто чистка состояния должна произойти, когда машина перезагружается в следующий раз. должны быть инструменты для контроля дескрипторов файлов и использования файла приложений - например, 'strace' инструмент показывает некоторые основные возможности. (существуют еще некоторые усовершенствованные подходы там для такого вида контроля, некоторые из них все еще основаны на запасе 'strace' двоичный файл.) просто контроль способных списком файлов в системе, вероятно, менее вероятно, представит первопричину для тех конкретный случай.