LINUX.ORG.RU

Постоянно ругается, что на рутовом разделе мало места

 ,


0

3

Здравствуйте!

Использую Ubuntu 13.04. и при загрузке постоянно получаю сообщение «На разделе „корень файловой системы“ осталось всего 79.0 МБ свободного места». Как отключить это сообщение я знаю, мне интересно, почему оно возникает, ведь на корне места должно быть достаточно. Но. df почему-то тоже показывает, что места нет:

[c0der@rock ~]$ df -h
Файл.система   Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sda2        9,8G         9,2G   76M          100% /
none             4,0K            0  4,0K            0% /sys/fs/cgroup
udev             3,9G         4,0K  3,9G            1% /dev
tmpfs            794M         888K  793M            1% /run
none             5,0M            0  5,0M            0% /run/lock
none             3,9G         156K  3,9G            1% /run/shm
none             100M          52K  100M            1% /run/user
/dev/sda1        468M          54M  390M           13% /boot
/dev/sdb8         40G          12G   26G           31% /mnt/music
/dev/sdb7        670G         5,5G  630G            1% /mnt/video
/dev/sdb6        118G          60M  112G            1% /mnt/data
/dev/sdb1         12G         966M   11G            9% /var
/dev/sdb2        7,9G         1,1M  7,5G            1% /tmp
/dev/sdb3         20G         628M   18G            4% /opt
/dev/sdb5         40G          29G  8,4G           78% /home

Т.к. у меня /boot, /var, /tmp, /opt и /home находятся на отдельных разделах, то неясно почему вдруг корень так забит. У меня есть предположение, что каким-то образом они не примонтированы и файлы реально пишутся в корень, хотя должны быть на соответствующих разделах. Но, в таком случае, эти каталоги должны быть не примонтированы, а это не так:

[c0der@rock ~]$ mount
/dev/sda2 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
/dev/sda1 on /boot type ext2 (rw)
/dev/sdb8 on /mnt/music type ext4 (ro,noexec,nosuid,nodev,noatime,nodiratime)
/dev/sdb7 on /mnt/video type ext4 (rw,noexec,nosuid,nodev,noatime,nodiratime)
/dev/sdb6 on /mnt/data type ext4 (rw,noexec,nosuid,nodev,noatime,nodiratime)
/dev/sdb1 on /var type ext4 (rw)
/dev/sdb2 on /tmp type ext2 (rw)
/dev/sdb3 on /opt type ext4 (rw)
/dev/sdb5 on /home type ext4 (rw)
gvfsd-fuse on /run/user/coder/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=coder)

Есть идеи что не так и как с этим разобраться?

P.S. Возможно, что это важно, но / и /boot находятся на отдельном винте, который SSD.

★★★★★

Последнее исправление: php-coder (всего исправлений: 1)
Ответ на: комментарий от ritsufag

Логи в /var/log обычно, а он на отдельном разделе. В любом случае, это вряд ли из-за них:

[c0der@rock ~]$ du -sh /var
936M	/var
php-coder ★★★★★
() автор топика
Ответ на: комментарий от Anon

Нет, не часто. Кэш не чистил, но, думаю, что он не причем — кэш apt-а находится в /var, который на отдельном разделе. На всякий случай проверил: /var/cache/apt занимает 316 МБ

php-coder ★★★★★
() автор топика
Ответ на: комментарий от Anon
[c0der@rock ~]$ sudo du -xs /*
9928	/bin
54699	/boot
4	/cdrom
4	/dev
14244	/etc
30331600	/home
0	/initrd.img
0	/initrd.img.old
392808	/lib
4	/lib64
16	/lost+found
12	/media
4	/mnt
597464	/opt
0	/proc
28	/root
888	/run
10652	/sbin
4	/selinux
4	/srv
0	/sys
124	/tmp
2735356	/usr
958316	/var
0	/vmlinuz
0	/vmlinuz.old
php-coder ★★★★★
() автор топика

Почисти /dev/sda2 (хотя бы sudo apt-get clean), а если не получится удалить достаточно, то отключи напоминалку:

sudo apt-get install -y dconf-tools && dconf-editor

Потом просто снять галочку:

org > gnome > settings-deamon > plugins > housekeeping

sh4r4t4n
()

Посмотри использование пространства на диске baobab'ом. Ну и взгляни на всякий случай на df -i.

Lighting ★★★★★
()
Ответ на: комментарий от php-coder

вы du и df не сравнивайте - они разное показывают. Удаляйте доки!

anonymous
()
Ответ на: комментарий от Anon
9,7M	/bin
54M	/boot
4,0K	/cdrom
4,0K	/dev
14M	/etc
29G	/home
0	/initrd.img
0	/initrd.img.old
384M	/lib
4,0K	/lib64
16K	/lost+found
12K	/media
4,0K	/mnt
584M	/opt
0	/proc
28K	/root
888K	/run
11M	/sbin
4,0K	/selinux
4,0K	/srv
0	/sys
124K	/tmp
2,7G	/usr
936M	/var
0	/vmlinuz
0	/vmlinuz.old
php-coder ★★★★★
() автор топика
Ответ на: комментарий от Lighting

Уже смотрел. Даже под sudo его запускал (нагуглил где-то в интернете), думал, что увижу что-нибудь чего не видно обычным юзером.

php-coder ★★★★★
() автор топика
Ответ на: комментарий от php-coder

Перезагрузись: у тебя что-то использует большой файл, который ты удалил.

Сам ведь видишь, что размер корня по du не соответствует размеру по df!

Набери еще: du -hxs / от рута

Anon
()
Ответ на: комментарий от php-coder

Странный вывод для du -x, посмотри внутрь каталогов /var и т.д. при отмонтированных системах. Возможно, в них что-то лежит и при монтировании прячется.

kvap
()
Ответ на: комментарий от php-coder

Пройдись по sda2 fsck'ом.

Хотя где-то на задворках памяти у меня всплывают воспоминания о похожем баге какой-то FS. (Возможно даже ext4, по крайней мере быстрый гуглёж говорит, что ты не единственный с похожей проблемой: «место есть, а места нет».)

touch /forcefsck && reboot
beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 3)
Ответ на: комментарий от php-coder

Хм-м... вообще говоря, у меня была однажды такая ситуация на Генте, что место должно было быть, но пропало не пойми куда. То ли на ext3, то ли на ext4. Хорошо так пропало, десятки гигабайт. Спрашивал на ЛОРе, причина не нашлась, помогло только архивирование всего на отдельный диск, переформатирование и восстановление.

Но для начала рекомендую сделать fsck. И запостить сюда свой /etc/fstab, может, там какие-то крокодилы.

Иногда помогает осмотр при помощи baobab или gdmap. Но в этом случае вряд ли, тут расчёты du и df, я гляжу, не сходятся, скорее всего, проблема в ФС или в том, как они монтируются.

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 2)
Ответ на: комментарий от Anon

Перезагрузись: у тебя что-то использует большой файл, который ты удалил.

Это не помогает. Проблема постояннно воспроизводится.

php-coder ★★★★★
() автор топика
Ответ на: комментарий от Deneb

Если не секрет, зачем такая разметка?

У меня корень на SSD, а остальные данные на HDD. Соответственно, чтобы не убивать SSD и из-за того, что на нём всего 16 Гб, я вынес разделы с интенсивной записью, либо занимающие много места (например, /home).

php-coder ★★★★★
() автор топика
Ответ на: комментарий от Ip0

Там куча всего, 359 строк. Запостить на pastebin или достаточно самого факта их присутствия?

Что это значит?

php-coder ★★★★★
() автор топика
Ответ на: комментарий от hardsky

Нашел одно. Удалил. Сомневаюсь, что поможет, но попробую.

php-coder ★★★★★
() автор топика
Ответ на: комментарий от proud_anon

fstab покажи

UUID=23322294-0554-41d1-aa27-8906030314ff	/	ext4	errors=remount-ro	0	1
UUID=5638ec52-2cd3-4d9c-a150-0ac9c1f6f29a	/boot	ext2	defaults	0	2
UUID=2341fdc0-3a43-443c-af80-a5f3f3cdc4cb	/home	ext4	defaults	0	2
LABEL=MUSIC	/mnt/music	ext4	defaults,ro,noexec,nosuid,nodev,noatime,nodiratime	0	0
LABEL=VIDEO	/mnt/video	ext4	defaults,noexec,nosuid,nodev,noatime,nodiratime	0	0
LABEL=DATA	/mnt/data	ext4	defaults,noexec,nosuid,nodev,noatime,nodiratime	0	0
UUID=9aa543a9-4af0-4ec1-bc17-c67ab15204d3	/opt	ext4	defaults	0	2
UUID=115ab3f3-814d-4246-adb4-0aa78b91ecc8	/tmp	ext2	defaults	0	2
UUID=c7f1d477-6287-49db-b6cd-118c56129e9f	/var	ext4	defaults	0	2
UUID=e2e7066d-2d12-499b-ae62-c6a906a45fe5	none	swap	sw	0	0

php-coder ★★★★★
() автор топика
Ответ на: комментарий от php-coder

Запости, да.

Это файлы помеченные как удаленные, но которые удерживает какой-либо процесс, в результате место на диске они всё еще занимают.

Ip0 ★★★★
()

Разобрался: я в какой-то момент умудрился записать данные в /mnt/data, когда тот был отмонтирован. И получилось так, что это записалось на раздел с корнем, а после монтирования /mnt/data с другого раздела содержимое каталога закрывалось содержимым примонтированного.

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