LINUX.ORG.RU
решено Форум — Admin  

Непонятки занятым местом в коневом разделе. Debian 8.3

 , ,


0

0

Проблема: не могу определить чем забито место в корневом разделе. 

df -h /
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/dm-1           19G          16G  2,5G           87% /

Видно, что в корневом разделе занято около 16 гб 

du -bshx /
5,7G    /

du -shx /
6,1G    /

Почему то du показывает, что занято только 6 гб. Еще 10 где то «висит». Попробовал посмотреть через ncdu: 

ncdu -x /
--- / -----------------------------------------------------------    
    3,0GiB [##########] /var
    1,2GiB [####      ] /usr
    1,0GiB [###       ] /opt
  598,6MiB [#         ] /root
  205,5MiB [          ] /lib
   84,3MiB [          ] /mnt
   10,9MiB [          ] /bin
    8,1MiB [          ] /etc
    7,0MiB [          ] /sbin
    4,8MiB [          ] /home
    1,8MiB [          ] /scripts
  348,0KiB [          ] /.git
   84,0KiB [          ] /tmp
e  16,0KiB [          ] /lost+found
    8,0KiB [          ] /media
    8,0KiB [          ] /srv
    4,0KiB [          ] /lib64
    4,0KiB [          ]  .gitignore
    4,0KiB [          ]  .gitignore~
@   0,0  B [          ]  initrd.img
@   0,0  B [          ]  vmlinuz
>   0,0  B [          ] /sys
>   0,0  B [          ] /run
>   0,0  B [          ] /proc
>   0,0  B [          ] /dev
>   0,0  B [          ] /boot
ncdu - показывает фактически тоже самое (около 6 гб занятого места).

Была мысль, что могут быть удалённые файлы, занятые в данный момент каким-либо процессом. Нагуглил, что можно их посмотреть: 

lsof / | grep deleted
mysqld     1701        mysql    4u   REG  254,1        0  652984 /tmp/ibb5Xnrq (deleted)
mysqld     1701        mysql    5u   REG  254,1        0  700236 /tmp/ib5M4Qiy (deleted)
mysqld     1701        mysql    6u   REG  254,1        0  700255 /tmp/ib91okaG (deleted)
mysqld     1701        mysql    7u   REG  254,1        0  700257 /tmp/ibHl7tWV (deleted)
mysqld     1701        mysql   11u   REG  254,1        0  700267 /tmp/ibhJXvk4 (deleted)
apache2    1955         root   18u   REG  254,1        0  700294 /tmp/.ZendSem.G8WLHI (deleted)
apache2    2059     www-data   18u   REG  254,1        0  700294 /tmp/.ZendSem.G8WLHI (deleted)
apache2    2060     www-data   18u   REG  254,1        0  700294 /tmp/.ZendSem.G8WLHI (deleted)
apache2    2061     www-data   18u   REG  254,1        0  700294 /tmp/.ZendSem.G8WLHI (deleted)
apache2    2062     www-data   18u   REG  254,1        0  700294 /tmp/.ZendSem.G8WLHI (deleted)
apache2    2063     www-data   18u   REG  254,1        0  700294 /tmp/.ZendSem.G8WLHI (deleted)
apache2    4637     www-data   18u   REG  254,1        0  700294 /tmp/.ZendSem.G8WLHI (deleted)
Отключил апач и Mysql, ситуация не изменилась, только список по "lsof / | grep deleted" стал пустым.

Пробовал просто перезагрузить систему, через команду reboot - проблема сохранилась в том же виде: не могу понять, чем забито место в корневом разделе.

Уже даже не знаю куда копать...


Ответ на: комментарий от Radjah

Файловая система: ext4 

/dev/mapper/bella--vg-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
снапшотов lvm нет (и не делались) 
lvscan
  ACTIVE            '/dev/bella-vg/root' [18,90 GiB] inherit
  ACTIVE            '/dev/bella-vg/swap_1' [872,00 MiB] inherit

swazd
() автор топика
Ответ на: комментарий от swazd

Во первых смотри с какими параметрами создавалась фс и сравнивай с тем какие размером и сколько файлов на ней хранятся.

А во вторых емнип по умолчанию 5% на ext4 резервируется под юзера root.

anonymous
()
Ответ на: комментарий от anonymous

ФС сразу создавалась такого размера. Диск 20 гб был размечен установщиком дебиана и потом не увеличивался. 

tune2fs -l /dev/mapper/bella--vg-root
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          96ffe421-3955-4fe3-a591-2d9bac7f4e29
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1240320
Block count:              4955136
Reserved block count:     247756
Free blocks:              884309
Free inodes:              999345
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Flex block group size:    16
Filesystem created:       Thu Feb  4 09:59:02 2016
Last mount time:          Mon Jul 17 08:17:13 2017
Last write time:          Mon Jul 17 08:17:10 2017
Mount count:              19
Maximum mount count:      -1
Last checked:             Thu Feb  4 09:59:02 2016
Check interval:           0 (<none>)
Lifetime writes:          3178 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       700284
Default directory hash:   half_md4
Directory Hash Seed:      fb3880ad-b340-4fab-9f23-608faf14063c
Journal backup:           inode blocks

5% резерв - ок. От 20 гб, 5% - это 1 GB, еще девять осталось найти.

«сравнивай с тем какие размером и сколько файлов на ней хранятся» Не очень понял как это сделать. du/ncdu показывает 6 гб занятых - я так понимаю это сумма размеров всех файлов, которые эта утилита нашла.

swazd
() автор топика
Ответ на: комментарий от FluffyPillow 
lsblk -a
NAME                   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                      8:0    0   20G  0 disk
├─sda1                   8:1    0  243M  0 part  /boot
├─sda2                   8:2    0    1K  0 part
└─sda5                   8:5    0 19,8G  0 part
  └─sda5_crypt         254:0    0 19,8G  0 crypt
    ├─bella--vg-root   254:1    0 18,9G  0 lvm   /
    └─bella--vg-swap_1 254:2    0  872M  0 lvm   [SWAP]
sdb                      8:16   0   40G  0 disk
sr0                     11:0    1 1024M  0 rom
swazd
() автор топика
Ответ на: комментарий от swazd

df может иногда врать. Попробуйте создать dd файл в 3ГБ (больше чем предел доступного места определяемого df) и если dd отработает без ошибок, то df врёт.

Создать файлик можно так:

dd if=/dev/zero of=/test.img bs=1M count=3000
FluffyPillow ★
()
Ответ на: комментарий от FluffyPillow 
 dd if=/dev/zero of=/test.img bs=1M count=3000
3000+0 записей получено
3000+0 записей отправлено
 скопировано 3145728000 байт (3,1 GB), 7,01892 c, 448 MB/c

df врёт.

dd if=/dev/zero of=/test2.img bs=1M count=3000
dd: ошибка записи «/test2.img»: На устройстве не осталось свободного места
435+0 записей получено
434+0 записей отправлено
 скопировано 455839744 байта (456 MB), 1,92471 c, 237 MB/c

df почему то врёт где то на 1 гб. Реально около 3.5 свободно. Т.е осталось найти куда делось еще 8 гб. После удаления тестовых файлов, df все еще показывает 2.5 гб свободно.

swazd
() автор топика
Ответ на: комментарий от joy4eg

Может вы можете помочь? через /dev/zero файл создаётся быстрее. Какая разница, как создать файл? Это оказался довольно действенный способ проверки, что df - врёт.

swazd
() автор топика
Ответ на: комментарий от joy4eg

Почему же вредные? Если только из-за возможности полностью забить диск не оставив ни байта свободного места. И почему urandom? zero даёт такой же результат,а нагрузка на цп меньше.

FluffyPillow ★
()
Ответ на: комментарий от int13h

очень плохой эксперемент на сервере

Откуда вы знаете что это делается на сервере? Что у ТС apache2 и mysql? Так они могут быть и на десктопе и использоваться в качестве тестирования/разработки сайтов. И да, таким способом места действительно не останется, даже на /tmp /var/log, и некоторый софт не сможет нормально отрабатывать. Но как проверка места - отличный, надежный вариант.

FluffyPillow ★
()
Ответ на: комментарий от FluffyPillow

LUKS. Стандартное шифрование от установщика Debian (он всё настроил) 

vgdisplay
  Couldn't find device with uuid YoBOMH-MAQe-KbqT-Ncbb-TxV7-09mR-EcNGVg.
  --- Volume group ---
  VG Name               bella-vg
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               2
  Max PV                0
  Cur PV                2
  Act PV                1
  VG Size               519,75 GiB
  PE Size               4,00 MiB
  Total PE              133056
  Alloc PE / Size       94657 / 369,75 GiB
  Free  PE / Size       38399 / 150,00 GiB
  VG UUID               uyFNVh-6pJ4-V4QG-RhZw-DPH6-Ms4F-DbxJRn


lvdisplay
  Couldn't find device with uuid YoBOMH-MAQe-KbqT-Ncbb-TxV7-09mR-EcNGVg.
  --- Logical volume ---
  LV Path                /dev/bella-vg/root
  LV Name                root
  VG Name                bella-vg
  LV UUID                dHRPyY-0y1p-AVVC-aVwC-jBgO-pPsS-s6Z1NI
  LV Write Access        read/write
  LV Creation host, time mizu, 2016-02-04 09:58:21 +0300
  LV Status              available
  # open                 1
  LV Size                18,90 GiB
  Current LE             4839
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:1

  --- Logical volume ---
  LV Path                /dev/bella-vg/swap_1
  LV Name                swap_1
  VG Name                bella-vg
  LV UUID                3gmbc8-aPeM-z5oe-DbpM-DaP1-opy5-div12v
  LV Write Access        read/write
  LV Creation host, time mizu, 2016-02-04 09:58:21 +0300
  LV Status              available
  # open                 2
  LV Size                872,00 MiB
  Current LE             218
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:2

  --- Logical volume ---
  LV Path                /dev/bella-vg/vmail
  LV Name                vmail
  VG Name                bella-vg
  LV UUID                1l6rRm-xfwU-J8fz-uSMl-ZO1H-p5oO-DERlcN
  LV Write Access        read/write
  LV Creation host, time bella, 2016-08-17 10:07:29 +0300
  LV Status              NOT available
  LV Size                350,00 GiB
  Current LE             89600
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

 pvdisplay
  Couldn't find device with uuid YoBOMH-MAQe-KbqT-Ncbb-TxV7-09mR-EcNGVg.
  --- Physical volume ---
  PV Name               /dev/mapper/sda5_crypt
  VG Name               bella-vg
  PV Size               19,76 GiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              5057
  Free PE               0
  Allocated PE          5057
  PV UUID               1jAMkh-8nFh-UA50-KgS6-OpYo-Sd8Z-cgUC2z

  --- Physical volume ---
  PV Name               unknown device
  VG Name               bella-vg
  PV Size               500,00 GiB / not usable 2,00 MiB
  Allocatable           yes
  PE Size               4,00 MiB
  Total PE              127999
  Free PE               38399
  Allocated PE          89600
  PV UUID               YoBOMH-MAQe-KbqT-Ncbb-TxV7-09mR-EcNGVg

очень плохой эксперемент на сервере

Ну, не очень то и плохой). На нём и нет толком ничего. И уж тем более от него не зависит ничья работа.

swazd
() автор топика
Ответ на: комментарий от swazd

(он всё настроил)

Не люблю всю автоматику - такие проблемы и всплывают от неё... Если есть возможность, из LiveCD сделайте бэкап всего важного, уберите всю текущую разбивку и вручную прикрутите LUKS+LVM, только не забудьте оставить место под boot. Это радикальный способ, но проблему решить должно (у самого так сделано, без автоматики).

FluffyPillow ★
()
Ответ на: комментарий от FluffyPillow

Удалил недостающий диск:

pvdisplay
  --- Physical volume ---
  PV Name               /dev/mapper/sda5_crypt
  VG Name               bella-vg
  PV Size               19,76 GiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              5057
  Free PE               0
  Allocated PE          5057
  PV UUID               1jAMkh-8nFh-UA50-KgS6-OpYo-Sd8Z-cgUC2z

lvdisplay
  --- Logical volume ---
  LV Path                /dev/bella-vg/root
  LV Name                root
  VG Name                bella-vg
  LV UUID                dHRPyY-0y1p-AVVC-aVwC-jBgO-pPsS-s6Z1NI
  LV Write Access        read/write
  LV Creation host, time mizu, 2016-02-04 09:58:21 +0300
  LV Status              available
  # open                 1
  LV Size                18,90 GiB
  Current LE             4839
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:1

  --- Logical volume ---
  LV Path                /dev/bella-vg/swap_1
  LV Name                swap_1
  VG Name                bella-vg
  LV UUID                3gmbc8-aPeM-z5oe-DbpM-DaP1-opy5-div12v
  LV Write Access        read/write
  LV Creation host, time mizu, 2016-02-04 09:58:21 +0300
  LV Status              available
  # open                 2
  LV Size                872,00 MiB
  Current LE             218
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:2

vgdisplay
  --- Volume group ---
  VG Name               bella-vg
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  10
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               19,75 GiB
  PE Size               4,00 MiB
  Total PE              5057
  Alloc PE / Size       5057 / 19,75 GiB
  Free  PE / Size       0 / 0
  VG UUID               uyFNVh-6pJ4-V4QG-RhZw-DPH6-Ms4F-DbxJRn
swazd
() автор топика
Ответ на: комментарий от FluffyPillow

Не люблю всю автоматику - такие проблемы и всплывают от неё... Если есть возможность, из LiveCD сделайте бэкап всего важного, уберите всю текущую разбивку и вручную прикрутите LUKS+LVM, только не забудьте оставить место под boot. Это радикальный способ, но проблему решить должно (у самого так сделано, без автоматики).

Это как то слишком радикально. Я надеялся понять как это можно исправить «правильно» - без пере разбивки/форматирования. Потому что есть и критичные сервера, которые тоже были через «автоматику» подняты. Пока там вроде всё норм, но никто не застрахован... Хотелось бы понять причину появления проблемы (хотя бы) и (в идеале) способы её устранения. Но, как безнадёжный вариант - можно и переделать.

swazd
() автор топика

На всякий случай df -i

anc ★★★★★
()
Ответ на: комментарий от FluffyPillow

В общем - разобрался. Как это часто бывает - оказался сам дурак. Проблема оказалась в том, что часть файлов (9+ГБ) лежали в директории, куда монтировалась сетевая папка. Т.е, получилось как то так: папка /mnt/store/backup/somedir_9GB была создана до того как смонтировалась сетевая папка /mnt/store/backup А я когда смотрел du - в папку /mnt/store/backup была примонтирована сетевая папка и папку /mnt/store/backup/somedir_9GB не было видно.

Разобрался, когда решился переносить систему на другой диск по совету FluffyPillow. Загрузился с LiveCD и решил в последний раз проверить раздел через du.

Всем спасибо!

swazd
() автор топика
Ответ на: комментарий от swazd

Проблема оказалась в том, что часть файлов (9+ГБ) лежали в директории, куда монтировалась сетевая папка.

:-) Интересно, а такие вещи без размонтирования ф/с, смонтированных поверх существующих данных, можно как-то ещё обнаружить?

aureliano15 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin