du, df и ls сообщают о неправильном свободном / использованном пространстве
У нас есть сервер Ubuntu 12.04, работающий на хосте VMware ESXi с несколькими разделами, работающий на Zimbra 8 (только mta/ldap). Один из разделов - это раздел размером 30 ГБ, смонтированный как /opt/zimbra/data. Сегодня утром я получил грубый звонок от моего менеджера о том, что почтовый сервер не работает.
Я вошел в систему и посмотрел, и, конечно же, все команды сообщали, что в разделе / opt / zimbra / data недостаточно свободного места. Я пытался выяснить, какой файл занимал все пространство, но df и du подвели меня. Вот выходные данные различных команд после того, как я отследил файл, выполнив один каталог за раз:
zimbra@mail:/opt/zimbra/data/ldap/mdb/db$ du -sh .
20M .
zimbra@mail:/opt/zimbra/data/ldap/mdb/db$ du --apparent-size data.mdb
31409532 data.mdb
zimbra@mail:/opt/zimbra/data/ldap/mdb/db$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sde1 30G 1.3G 28G 5% /opt/zimbra/data
zimbra@mail:/opt/zimbra/data/ldap/mdb/db$ ls -allh
total 20M
drwxr-xr-x 2 zimbra zimbra 4.0K Nov 26 13:50 .
drwxr-xr-x 3 zimbra zimbra 4.0K Jul 16 05:47 ..
-rw------- 1 zimbra zimbra 30G Nov 26 14:04 data.mdb
-rw------- 1 zimbra zimbra 8.0K Nov 26 14:07 lock.mdb
Обратите внимание, что файл data.mdb использует все 30 гигабайт, но не учитывается при сообщении общего пространства.
С тех пор мы создали новый раздел, скопировали файлы и запустили и запустили его, но мне все еще интересно, что могло бы привести к неправильным отчетам об использованном пространстве в разделе. У нас все еще лежит старый раздел, поэтому, если есть другие команды, о которых я не знаю, которые дадут более точные результаты, я бы хотел их опробовать.
Обновить:
Выход из ls -alsh
root@mail:/opt/zimbra/data/ldap/mdb/db# ls -alsh
total 20M
4.0K drwxr-xr-x 2 zimbra zimbra 4.0K Nov 26 13:50 .
4.0K drwxr-xr-x 3 zimbra zimbra 4.0K Jul 16 05:47 ..
20M -rw------- 1 zimbra zimbra 30G Nov 26 14:04 data.mdb
4.0K -rw------- 1 zimbra zimbra 8.0K Nov 26 14:07 lock.mdb
Таким образом, похоже, что файл действительно является разреженным файлом и был очень близок к размеру раздела. Я до сих пор не знаю, почему такие команды, как touch или же cp начал возвращаться no space left on disk, поскольку этот файл, кажется, фактически использует около 20 МБ.
Подводя итог, вот что я пришел, чтобы перечислить все файлы, включая разреженные, рекурсивно и упорядочить результаты по размеру файла desc:
ls -aldSh $(find .) | grep -v '^d'
Для любых пользователей Zimbra, которые могут оказаться здесь с подобной проблемой, следующие ссылки помогут:
MDB: максимальный размер базы данных
база данных ldap перешла с 97мег до 86гиг
Обновление 2:
Еще одна вещь, чтобы проверить, если в разделе закончились inode. Особый интерес представляют подкаталоги logger и zmstat. Они содержат несколько небольших файлов и могут быстро исчерпать inode перед тем, как исчерпать пространство, если они смонтированы на своих собственных разделах. Большинство команд по-прежнему возвращает ошибку "на устройстве не осталось места", что может вводить в заблуждение.
df -i может использоваться для отображения информации о количестве свободных инодов. Например, у меня есть раздел, который имеет около 80% свободного пространства в соответствии с df -h, но по-прежнему возвращает ошибку "на устройстве не осталось места", поскольку она не содержит inode:
root@mail:/opt/zimbra/logger# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdh1 20G 3.9G 16G 21% /opt/zimbra/logger
root@mail:/opt/zimbra/logger# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdh1 5120 5120 0 100% /opt/zimbra/logger