Файловая система заполнена 'df', но на самом деле не кажется
На моем сервере AIX 6.1 у меня проблема с VIO LPAR.
Файловая система пытается заполниться командой 'df', но не например, с "du" или "ls". Я искал, но не понимаю, откуда взялась проблема.
Команда 'df' показывает:
[root@VIO2] /var/vio/storagepools/VIO2_storfs_rvg #df -IMvm | grep var
/dev/hd9var /var 1024.00 497.91 526.09 49% 9226 122167 8%
/dev/livedump /var/adm/ras/livedump 256.00 0.36 255.64 1% 4 58200 1%
/dev/VIO2_storfs_rvg /var/vio/storagepools/VIO2_storfs_rvg 409600.00 409600.00 0.00 100% 39 57 41%
Команда 'du':
[root@VIO2] /var/vio/storagepools/VIO2_storfs_rvg #du -sx *
0 lost+found
41943040 rootvg_ge
41943040 rootvg_lp
41943040 rootvg_pr_en
41943040 rootvg_pr_gf
41943040 rootvg_pr_io
41943040 rootvg_pr_ot
41943040 rootvg_pr_si
41943040 rootvg_te_gf
3016960 rootvg_te_iodas
0 rootvg_te_ot
0 rootvg_te_si
37748736 te_hd
Команда 'ls':
[root@VIO2] /var/vio/storagepools/VIO2_storfs_rvg #ls -alR
total 376310120
drwxr-xr-x 3 root system 4096 Apr 22 22:27 .
drwxr-xr-x 3 root system 256 Jan 28 2016 ..
-rw-r--r-- 1 root system 219 Apr 21 09:54 .rootvg_ge
-rw-r--r-- 1 root system 221 Apr 21 09:55 .rootvg_lp
-rw-r--r-- 1 root system 224 Oct 28 10:58 .rootvg_pr_en
-rw-r--r-- 1 root system 219 Oct 28 10:59 .rootvg_pr_gf
-rw-r--r-- 1 root system 221 Oct 28 10:59 .rootvg_pr_io
-rw-r--r-- 1 root system 221 Oct 28 11:26 .rootvg_pr_ot
-rw-r--r-- 1 root system 219 Apr 21 09:56 .rootvg_pr_si
-rw-r--r-- 1 root system 219 Oct 28 11:01 .rootvg_te_gf
-rw-r--r-- 1 root system 221 Oct 28 11:01 .rootvg_te_io
-rw-r--r-- 1 root system 221 Oct 28 11:02 .rootvg_te_ot
-rw-r--r-- 1 root system 219 Apr 21 09:57 .rootvg_te_si
-rw-r--r-- 1 root system 211 Apr 21 10:07 .te_hd
drwxr-xr-x 2 root system 256 Jan 28 2016 lost+found
-rw-r--r-- 1 root system 21474836480 Apr 22 21:09 rootvg_ge
-rw-r--r-- 1 root system 21474836480 Apr 22 21:17 rootvg_lp
-rw-r--r-- 1 root system 21474836480 Apr 22 21:26 rootvg_pr_en
-rw-r--r-- 1 root system 21474836480 Apr 22 21:35 rootvg_pr_gf
-rw-r--r-- 1 root system 21474836480 Apr 22 21:44 rootvg_pr_io
-rw-r--r-- 1 root system 21474836480 Apr 22 21:53 rootvg_pr_od
-rw-r--r-- 1 root system 21474836480 Apr 22 22:02 rootvg_pr_si
-rw-r--r-- 1 root system 21474836480 Apr 22 22:11 rootvg_te_gf
-rw-r--r-- 1 root system 1544679424 Apr 22 22:11 rootvg_te_io
-rw-r--r-- 1 root system 0 Apr 22 22:19 rootvg_te_ot
-rw-r--r-- 1 root system 0 Apr 22 22:27 rootvg_te_si
-rw-r--r-- 1 root system 19327352832 Apr 24 08:08 te_hd
./lost+found:
total 8
drwxr-xr-x 2 root system 256 Jan 28 2016 .
drwxr-xr-x 3 root system 4096 Apr 22 22:27 ..
И еще немного 'fuser' команды:
[root@VIO2] /var/vio/storagepools/VIO2_storfs_rvg #fuser -dV /var/vio/storagepools/VIO2_storfs_rvg
/var/vio/storagepools/VIO2_storfs_rvg:
[root@VIO2] /var/vio/storagepools/VIO2_storfs_rvg #fuser -dV /var
/var:
Заранее спасибо, если кто-нибудь может объяснить!
Программа df сообщает объем пространства, доступного пользователю без полномочий root , независимо от того, кто ее запускает . Это было исторически верно, и я думаю, что так и остается. Рационально в том, что если обычная программа заполняет раздел, у root есть немного дополнительного рабочего пространства для решения проблемы. Это было особенно верно, если нарушающий процесс все еще пытался использовать все доступное пространство.
У меня нет доступа к машине AIX, но вы можете посмотреть в sys / mount.h , если он около.
iceberg /usr/include 521> grep f_bavail sys/mount.h
int64_t f_bavail; /* free blocks avail to non-superuser */
То же самое. У меня нет доступа к AIX Machine, но в Linux вы можете проверить процент, зарезервированный для root и служб командой:
sudo tune2fs -l / dev / sda1 | grep 'Reserved'
и измените его командой
sudo tune2fs -m 1 / dev / sdXY (здесь 1 процент зарезервирован)
Подробнее см. здесь: https: // unix .stackexchange.com / questions / 7950 / reserved-space-for-root-on-a-filesystem-why
Наконец, я решил проблему, размонтировав раздел (с опцией 'force', потому что кажется, что используется ...) и проверил согласованность с помощью 'fsck' перед повторным подключением.
I были ошибки: плохой суперблок, грязная карта распределения, грязная карта inode ...
'fsck' исправил эти ошибки, и после повторного монтирования все в порядке!
Спасибо за ваши ответы.
Я решил свою проблему, как сказал Тим С. в комментарии выше. Проблема заключалась в смонтированном разделе поверх папки, содержащей большой объем данных.
В моем случае сценарий резервного копирования скопировал 100 ГБ в «/media/backup-data», когда раздел, который обычно монтируется там, на самом деле не был смонтирован. Таким образом, файлы оказались на самом корневом разделе. В конце концов, когда обычный раздел был смонтирован в «/media/backup-data», «du» видел смонтированный раздел, но не файлы в корневом разделе в той же папке. Напротив, «df» видел файлы в корневом разделе. Отсюда и разница между "df -h" и "du -shx/".
В моем случае просто размонтируйте все разделы и проверьте, не находит ли du что-либо необычное в корневом разделе.