Расхождение между df и du

У меня есть вопрос, касающийся различий между "df -h" и "du -bs". Я видел несколько вопросов по этому поводу, но проблема заключалась в том, что df -h сообщал о более занятом пространстве, чем du -bs. У меня противоположная проблема:

[root @ CDPPRIM01 oracle-dbf] # du -bs
336178610176.

[root @ CDPPRIM01 файлы данных] # df -h | grep dbf
/ dev / sda2 360G 272G 85G 77% / opt / oracle-dbf

[root @ CDPPRIM01 datafiles] # ls -la
всего 284550000
drwxrwxr-x 2 oracle oinstall        4096 9 апреля 14:13 .
drwxr-xr-x 4 root   root            4096 апр. 3 10:33..
-rw-r ----- 1 оракул dba 9748480 11 апреля 17:01 control01.ctl
-rw-r ----- 1 оракул dba 9748480 11 апреля 17:01 control02.ctl
-rw-r ----- 1 оракул dba 968892416 11 апреля 16:20 pn310_admin_DATA22.dbf
-rw-r----- 1 оракул dba 104865792 11 апреля 16:20 pn310_admin_DATA.dbf
-rw-r----- 1 оракул dba 32212262912 11 апр. 16:20 pn310_DATA11.dbf
-rw-r----- 1 oracle dba      32212262912 11 апреля, 17:00 pn310_DATA12.dbf
-rw-r----- 1 oracle dba      32212262912 11 апреля 17:00 pn310_DATA13.dbf
-rw-r----- 1 оракул dba 32212262912 11 апреля 16:20 pn310_DATA14.dbf
-rw-r----- 1 оракул dba 5242888192 11 апреля 17:01 pn310_DATA15.dbf
-rw-r----- 1 оракул dba 1073750016 11 апреля 17:00 pn310_DATA.dbf
-rw-r----- 1 оракул dba 5798633472 11 апреля 16:20 pn310_dwe_DATA20.dbf
-rw-r----- 1 оракул dba 1073750016 11 апреля 16:20 pn310_dwe_DATA.dbf
-rw-r----- 1 оракул dba 104865792 3 апреля 10:42 pn310_dwe_TEMP.dbf
-rw-r----- 1 оракул dba 5263859712 3 апреля, 11:28 pn310_dwe_temp_TEMP9.dbf
-rw-r----- 1 оракул dba 32212262912 11 апреля 16:20 pn310_ep_DATA16.dbf
-rw-r----- 1 oracle dba      32212262912 11 апреля 16:20 pn310_ep_DATA17.dbf
-rw-r----- 1 оракул dba 32212262912 11 апреля 16:20 pn310_ep_DATA18.dbf
-rw-r----- 1 оракул dba 9437192192 11 апреля 16:20 pn310_ep_DATA19.dbf
-rw-r----- 1 оракул dba 1073750016 11 апреля 16:50 pn310_ep_DATA.dbf
-rw-r----- 1 оракул dba 104865792 3 апреля 10:42 pn310_ep_TEMP.dbf
-rw-r----- 1 оракул dba 16001277952 3 апреля 11:27 pn310_ep_temp_TEMP8.dbf
-rw-r----- 1 оракул dba 104865792 11 апреля 06:00 pn310_TEMP.dbf
-rw-r----- 1 оракул dba 16001277952 11 апреля 17:01 pn310_temp_TEMP7.dbf
-rw-r----- 1 оракул dba 11811168256 11 апреля 16:51 pn310_xmp_DATA21.dbf
-rw-r----- 1 оракул dba 1073750016 11 апреля 17:00 pn310_xmp_DATA.dbf
-rw-r----- 1 оракул dba 104865792 3 апреля 10:42 pn310_xmp_TEMP.dbf
-rw-r----- 1 оракул dba 2042634240 3 апреля, 11:29 pn310_xmp_temp_TEMP10.dbf
-rw-r----- 1 оракул dba 566239232 11 апр. 17:00 sysaux01.dbf
-rw-r----- 1 оракул dba 4802486272 11 апреля 16:57 sysaux_DATA24.dbf
-rw-r----- 1 оракул dba 754982912 11 апр. 16:58 system01.dbf
-rw-r----- 1 оракул dba 4613742592 11 апреля 17:00 system_DATA23.dbf
-rw-r----- 1 оракул dba 1073750016 10 апр. 23:07 temp01.dbf
-rw-r----- 1 оракул dba 1073750016 апр. 3 10:38 temp02.dbf
-rw-r----- 1 оракул dba 3221233664 3 апреля, 11:31 temp_TEMP11.dbf
-rw-r----- 1 оракул dba 1073750016 11 апреля 17:01 undotbs01.dbf
-rw-r----- 1 оракул dba 1073750016 11 апреля 17:00 undotbs02.dbf
-rw-r----- 1 оракул dba 13958651904 11 апреля 17:01 undotbs1_DATA26.dbf
-rw-r----- 1 оракул dba 5251072 11 апр. 16:20 users01.dbf
-rw-r----- 1 оракул dba 1068507136 11 апреля 16:20 users_DATA25.dbf

При добавлении всех файлов мы получаем 336178593792, что в ГБ равно: 336178593792/1024/1024/1024 = 313 ГБ, что больше, чем 272 ГБ, о которых сообщает df -h.

Я уже сделал umount и fsck, чтобы проверить раздел, и он чистый. Кто-нибудь знает, что может быть причиной этого поведения?

Источник

2 ответа

Я не совсем уверен, что здесь происходит, но я могу дать вам несколько советов.

  1. du -b подразумевает --apparent-size вариант. От du справочная страница:

    --apparent-size
      print  apparent  sizes,  rather than disk usage; although the apparent
      size is usually smaller, it may be larger due to holes in (`sparse')
      files,  internal  fragmentation, indirect blocks, and the like
-b, --bytes
      equivalent to `--apparent-size --block-size=1'

  2. Я не уверен, как oracle работает с файлами базы данных, но меня не удивит, если некоторые из них действительно будут редкими. Я думаю, что это наиболее вероятная причина, см. Здесь для обсуждения того, как это может повлиять du,

  3. На этой странице есть хорошее объяснение некоторых различий между способами расчета использования диска двумя программами.

  4. Немного более актуальной информации от df справочная страница:

    -h, --human-readable
      print sizes in human readable format (e.g., 1K 234M 2G)
Display values are in units of the first available  SIZE  from
--block-size,  and the DF_BLOCK_SIZE, BLOCK_SIZE and BLOCKSIZE
environment variables.  Otherwise, units default to 1024 bytes
(or 512 if POSIXLY_CORRECT is set).

SIZE  may be (or may be an integer optionally followed by) one
of following: KB 1000, K 1024, MB 1000*1000, M 1024*1024,  and
so on for G, T, P, E, Z, Y.
Источник

Одна возможность была бы редкими файлами. Если большие части данного файла не содержат данных, никакие физические блоки не должны быть выделены для этих частей файла, при условии, что ОС и файловая система поддерживают это.

Чтобы проверить наличие разреженных файлов, используйте invoke ls с переключателями -s (показать место на жестком диске) и -k (показать размеры в кибибайтных блоках).

Пример вывода:

$ df -H /dev/sda1
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       118G   38G   75G  34% /
$
$ dd if=/dev/zero of=1GB-normal bs=1GB count=1 # normal file (1 GB)
$
$ df -H /dev/sda1
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       119G   38G   75G  34% /
$
$ dd if=/dev/zero of=1GB-sparse bs=1GB count=0 seek=1GB # sparse file (1 GB)
$
$ df -H /dev/sda1
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       119G   38G   75G  34% /
$
$ ls -lks
total 976568
976568 -rw-rw-r-- 1 dennis dennis 976563 Apr 11 13:05 1GB-normal
     0 -rw-rw-r-- 1 dennis dennis 976563 Apr 11 13:06 1GB-sparse

Поскольку разреженный файл не занимает (почти) физическое пространство на диске, вывод df не изменяется после его создания.

Источник
Другие вопросы по тегам