Все началось пару недель назад:
"E297: Write error in swap file$ echo "test" > test производит -bash: echo: write error: No space left on deviceЭто не моя квота, как это бывает со всеми пользователями.
Кроме того, сервер кажется быть в порядке ...
Думаю, это может быть рут / своп, но как исправить не знаю.
Вот некоторая информация, которая, я думаю, может быть полезна:
$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/fileserver--00-root
224G 212G 0 100% /
none 995M 192K 995M 1% /dev
none 1000M 0 1000M 0% /dev/shm
none 1000M 14M 986M 2% /var/run
none 1000M 0 1000M 0% /var/lock
none 1000M 0 1000M 0% /lib/init/rw
/dev/sdb1 1.4T 1006G 356G 74% /cubo/d2p1
/dev/sdc1 459G 416G 39G 92% /cubo/d3p1
/dev/sda1 228M 17M 199M 8% /boot
192.168.1.7:/nfs/Backups
1.8T 1.2T 645G 65% /cubo/nfsMounts/ixBackup
Также:
$ ll /dev/mapper/
total 0
crw-rw---- 1 root root 10, 59 2013-04-11 12:54 control
brw-rw---- 1 root disk 251, 0 2013-04-11 12:54 fileserver--00-root
brw-rw---- 1 root disk 251, 1 2013-04-11 12:54 fileserver--00-swap_1
Дополнительная информация
$ sudo dmsetup status
fileserver--00-swap_1: 0 11993088 linear
fileserver--00-root: 0 475701248 linear
И:
$ sudo dmsetup info
Name: fileserver--00-swap_1
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 1
Event number: 0
Major, minor: 251, 1
Number of targets: 1
UUID: LVM-z7USJS3uIlf3VVUPeDeE0TzljgezS31fcvrwZihBYEENf5Tkgsyb9xJHo3RNVXsT
Name: fileserver--00-root
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 1
Event number: 0
Major, minor: 251, 0
Number of targets: 1
UUID: LVM-z7USJS3uIlf3VVUPeDeE0TzljgezS31fdr57i4JAzZxlK6KeTOWDTm6bzUKK87J1
Размер моих корневых папок:
$ cd /
$ sudo du -sh {bin,boot,cdrom,dev,etc,home,lib,lost+found,media,mnt,opt,proc,root,sbin,selinux,srv,sys,tmp,usr,var}
7.4M bin
17M boot
4.0K cdrom
192K dev
39M etc
1.1M home
154M lib
16K lost+found
4.0K media
4.0K mnt
4.0K opt
du: cannot access `proc/21251/task/21251/fd/4': No such file or directory
du: cannot access `proc/21251/task/21251/fdinfo/4': No such file or directory
du: cannot access `proc/21251/fd/4': No such file or directory
du: cannot access `proc/21251/fdinfo/4': No such file or directory
0 proc
48K root
7.5M sbin
4.0K selinux
4.0K srv
0 sys
16K tmp
542M usr
282M var
Мой fstab:
$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
/dev/mapper/fileserver--00-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=1724d880-01a4-481c-87e5-08328c3c8137 /boot ext2 defaults 0 2
/dev/mapper/fileserver--00-swap_1 none swap sw 0 0
/dev/sdb1 /cubo/d2p1 ext3 defaults 0 0
/dev/sdc1 /cubo/d3p1 ext4 defaults 0 0
/dev/sdd1 /cubo/d4p1 ext4 defaults,noauto 0 0
192.168.1.7:/nfs/Backups /cubo/nfsMounts/ixBackup nfs defaults 0 0
Как это исправить?
Как я уже сказал в другом месте, у вас заполнен корневой раздел.
Линия 224G 212G 0 100% / подсказка, вы используете 100% файловой системы, смонтированной на /.
После исследования проблемы в чате причина была определена - пространство в корневой файловой системе было занято файлами, скрытыми под точками монтирования (и, следовательно, невидимыми для du).
В Linux есть два способа доступа к файлам и каталогам, скрытым под точками монтирования:
Очевидный способ - размонтировать файловую систему, смонтированную над каталогом, а затем посмотреть, что находится внутри этого каталога. Очевидно, что это невозможно сделать, пока файловая система используется.
Используя монтирование привязки, внешнюю файловую систему можно сделать доступной в другом каталоге в дереве, а обычные монтирования привязки не рекурсивны - они не копируют вложенные монтирования, поэтому каталоги, которые были перемонтированы в старом месте, становятся доступными в новом месте. Это можно сделать на работающей машине, не прерывая операций, использующих файловую систему, поэтому здесь будет использоваться этот метод.
Команды для выполнения такого монтирования привязки для корневой файловой системы:
sudo mkdir /mnt/tmp_root
sudo mount --bind / /mnt/tmp_root
(В этом случае использование /mnt/tmp_root было возможно, потому что пространство, зарезервированное для root, было использовано не на 100%.)
Тогда возможно найти большие файлы, скрытые под точками монтирования:
sudo du -x --max-depth=1 /mnt/tmp_root
sudo du -x --max-depth=1 /mnt/tmp_root/cubo
...
После обнаружения проблемных файлов их можно удалить, чтобы освободить место. Обратите внимание, что невозможно удалить каталоги, которые используются в качестве точек монтирования в других монтированиях привязки той же файловой системы - например, если файловая система NFS смонтирована в /cubo/nfsMounts/ixBackup, удаление /mnt/tmp_root/cubo/nfsMounts/ixBackup невозможно (но файлы и каталоги под ним можно удалить).
Наконец, способ защиты от таких проблем в будущем - ужесточить разрешения для каталогов, которые предназначены для использования в качестве точек монтирования, чтобы в случае возникновения проблем, препятствующих монтированию (например, сервер NFS не отвечает), каталог недоступен, и попытки доступа к нему очевидным образом терпят неудачу:
sudo chown root:root /mnt/tmp_root/cubo/nfsMounts/ixBackup
sudo chmod 0600 /mnt/tmp_root/cubo/nfsMounts/ixBackup
(Это изменяет права доступа к каталогу в корневой файловой системе и ничего не делает с файловой системой, которая может быть смонтирована в /cubo/nfsMounts/ixBackup.)
Последняя операция - удалить привязку монтирования, когда она больше не нужна, и удалить временный каталог:
sudo umount /mnt/tmp_root
sudo rmdir /mnt/tmp_root