Влияние кэша диска на результат df в Linux

Влияние кэша диска на результат df в Linux

У меня проблема, в которой регистр df приводит к ненадежным результатам. Я использую файловую систему xfs на sles 11 sp3.
По сути, есть большая разница (несколько ГБ) между свободным размером до и после очистки кэша диска. Кто-нибудь знает, почему diskcache использует дополнительное хранилище.
Например:

VideoEdge:/ # df
Filesystem     1K-blocks      Used Available Use% Mounted on
...
/dev/sdb2      870942208 824794856  46147352  95% /mediadb
/dev/sdc1      975746564 924536548  51210016  95% /mediadb1
/dev/sdd1      975746564 153177500 822569064  16% /mediadb2

VideoEdge:/ # echo 3 > /proc/sys/vm/drop_caches 

VideoEdge:/ # df
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sdb2      870942208 822225756  48716452  95% /mediadb
/dev/sdc1      975746564 923374888  52371676  95% /mediadb1
/dev/sdd1      975746564 148323524 827423040  16% /mediadb2
VideoEdge:/ # df

Из вышесказанного следует, что после очистки дискового пространства становится больше свободного места.

Мы используем df для оценки того, сколько места может быть использовано, и пытаемся удалить старые данные, когда df сообщает, что stporage заполнен на 95%. Поскольку кэш диска занимает непредсказуемое место для хранения, это вызывает проблему.

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

Мы не хотим очищать кэш диска, поскольку это может время от времени снижать производительность.

VideoEdge:/ # df
Filesystem     1K-blocks      Used Available Use% Mounted on
rootfs           8259484   5592116   2247724  72% /
udev             2021220       228   2020992   1% /dev
tmpfs            2021220       144   2021076   1% /dev/shm
/dev/sda1        8259484   5592116   2247724  72% /
/dev/sda3      463282160  75389072 387893088  17% /var
/dev/sdb1      104804356     32928 104771428   1% /var/opt/americandynamics/venvr/clipexport
/dev/sdb2      870942208 821370196  49572012  95% /mediadb
/dev/sdc1      975746564 923423496  52323068  95% /mediadb1
/dev/sdd1      975746564 148299180 827447384  16% /mediadb2

/dev/sdb2 on /mediadb type xfs (rw,noatime,nodiratime,attr2,nobarrier,inode64,allocsize=4096k,noquota)
/dev/sdc1 on /mediadb1 type xfs (rw,noatime,nodiratime,attr2,nobarrier,inode64,allocsize=4096k,noquota)
/dev/sdd1 on /mediadb2 type xfs (rw,noatime,nodiratime,attr2,nobarrier,inode64,allocsize=4096k,noquota)

решение1

Пожалуйста, посмотри:

Почему мои файловые системы XFS внезапно стали занимать больше места и заполняться разреженными файлами?

Это результат динамических функций предварительного выделения XFS. По сути, это файловые буферы, которые объединяют записи для предотвращения фрагментации файлов. Есть несколько обходных путей.

  • du --apparent-sizeможет быть полезным.
  • Параметры монтирования для файловой системы XFS подробно описаны всвязанный вопрос.

В обоих случаях ваша файловая система находится на опасном уровне заполненности (95%+). Небольшой объем буферного пространства не имеет значения, учитывая, что у вас должно быть намного меньше 80% использования. Вы также можете использовать результаты, dfпоскольку это то, что действительно используется в любой момент времени.

Связанный контент