Я использую Dirvish в серверной системе Ubuntu для резервного копирования жесткого диска на внешний диск USB 3.0. Еще несколько дней назад все работало нормально, но теперь каждое резервное копирование завершается сбоем из-за «не осталось места на устройстве (28)» и «файловая система заполнена». К сожалению, не все так просто: на устройстве свободно> 500 ГБ.
Подробности:
rsync_error:
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]
журнал выглядит почти как обычно, пока не попадет:
<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1
Но, как уже было сказано выше, на устройстве много места:
df -h
/dev/sdg1 2.7T 2.0T 623G 77% /mnt/backupsys/shd
а также осталось много инодов:
df -i
/dev/sdg1 183148544 2810146 180338398 2% /mnt/backupsys/shd
Устройство смонтировано как rw:
mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)
Процесс запущен от имени пользователя root.
Я собирался сказать, что ничего не менял, но это не совсем так: я включил acl для диска, для которого создается резервная копия:
/dev/md0 on /mnt/md0 type ext4 (rw,acl)
Может ли это быть проблема? Если да, то как? root по-прежнему имеет полный доступ к файлам.
РЕДАКТИРОВАТЬ:
Я только что проверил временные каталоги:
файловая система, в которой находятся эти каталоги, имеет много свободного места и индексных дескрипторов:
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 289G 55G 220G 20% /
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 19202048 167644 19034404 1% /
РЕДАКТИРОВАТЬ2:
Каталоги довольно большие, но не более 2 ГБ. Тот, в котором происходит сбой резервного копирования, даже не один из самых больших, он содержит 7530 файлов.
РЕДАКТИРОВАТЬ3:
Одна информация, которую я не посчитал актуальной при публикации этого вопроса:
За день до начала сбоя резервного копирования я активировал ACL в файловых системах, для которых были созданы резервные копии. Я предполагаю, что это заставило Dirvish (или rsync) подумать, что все файлы изменились, поэтому список файлов, которые должны были быть скопированы, а не жестко связаны, был очень большим. Это могло означать, что некоторые буферы были слишком маленькими.
Сегодня полное резервное копирование на пустой диск прошло безупречно. Далее я попробую инкрементное резервное копирование. Это покажет, была ли активация ACL причиной проблемы.
Глядя на 2% оставшихся инодов, я задумался о корневых резервах, которые накладывает файловая система EXT. Вы можете проверить это:
Я бы попытался создать .tar.gz некоторые из старых резервных копий, надеясь, что это уменьшит количество используемых inode.
Мое подозрение (см. EDIT3), по-видимому, было правильным: добавление поддержки acl в файловую систему заставило rsync / dirvish думать, что все файлы были изменены. Поэтому вместо того, чтобы делать инкрементную резервную копию и просто создавать жесткие ссылки на уже существующие файлы, он пытался создать полную резервную копию, что, конечно же, не удалось, потому что на жестком диске не было достаточно места для этого.
Итак, сообщение об ошибке было правильным.
После повторного запуска с пустым резервным диском инкрементные резервные копии работали, как и раньше.
Я вижу, что dummzeuch нашел решение своей проблемы, но на самом деле я обнаружил еще один случай, когда на диске может быть достаточно inodes / свободного места, но при попытке переноса определенных каталогов по-прежнему отображается сообщение «на устройстве не осталось места».
Это вызвано конфликтами хэшей на блочных устройствах, отформатированных с файловой системой ext4, где также включена индексация каталогов, особенно если в одном каталоге содержится более 100 тыс. Файлов, а имена файлов генерируются с использованием одного и того же алгоритма (файлы кеша, имена файлов md5sum и т. Д. .)
Решение - попробовать использовать другой алгоритм индексации каталогов:
tune2fs -E "hash_alg=tea" /dev/blockdev_name
или полностью отключить индексацию каталогов для этого блочного устройства (может снизить производительность)
tune2fs -O ^dir_index /dev/blockdev_name
Другое решение - посмотреть, что наполняет каталог такими файлами, и исправить программное обеспечение.
Возможное решение - разделить содержимое папки с огромным объемом файлов на несколько отдельных подпапок.
Полное описание проблемы представлено Акселем Вагнером здесь.
http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
Ура.
Для самого каталога существует ограничение на размер 2 ГБ, то есть если у вас так много файлов, что размер каталога составляет> 2 ГБ (НЕ размер файлов в каталоге), у вас возникнет проблема. Сказав это, с использованием всего 2,8 млн inode, это не должно быть проблемой. Обычно происходит около 15 миллионов инодов.
Так что это может не сильно помочь, но попробовать ext4 на вашем устройстве резервного копирования?
Увеличьте лимит наблюдателей Inotify в sysctl:
fs.inotify.max_user_watches=100000
И перезагрузитесь, или сделайте sysctl -w версия этого тоже.
Обычно так бывает. Что-то в ядре открыто слишком много файлов, и ошибка полностью вводит в заблуждение. Dropbox - классический пример этого.
Я бы посоветовал вам проверить еще пару вещей:
Я только что нашел эту тему, когда искал решение своей проблемы.
Действительно, для ENOSPC есть по крайней мере другая причина. И я также нашел это с помощью rsync, копируя из файловой системы ZFS в EXT4:
rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)
В таком случае:
ENOSPC - There is insufficient space remaining to store the extended attribute.
man 7 xattr объясняет:
In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).
В моем случае это означает, что мне нужно переформатировать всю файловую систему. :-(