Есть ли какая-либо другая причина для «свободного места на устройстве»?

Я использую 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 по-прежнему имеет полный доступ к файлам.

РЕДАКТИРОВАТЬ:

Я только что проверил временные каталоги:

• / tmp содержит только пустую папку .webmin
• / var / tmp пуст

файловая система, в которой находятся эти каталоги, имеет много свободного места и inode:

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% /

EDIT2:

Каталоги довольно большие, но не более 2 ГБ. Тот, где резервная копия терпит неудачу, даже не один из самых больших, он содержит 7530 файлов.

EDIT3:

Одна информация, которую я не счел актуальной при публикации этого вопроса:

За день до сбоя резервного копирования я активировал acls на файловых системах, для которых были созданы резервные копии. Теперь я предполагаю, что это вызвало Dirvish (или rsync), чтобы думать, что все файлы изменились, поэтому список файлов, которые должны были быть скопированы, а не жестко связаны, был очень большим. Это может означать, что некоторые буферы были слишком маленькими.

Сегодня полное резервное копирование на пустой диск работало безупречно. Я попробую инкрементное резервное копирование в следующем. Это покажет, была ли активация acls причиной проблемы.

Мое подозрение (см. EDIT3), очевидно, было правильным: добавление поддержки acl в файловую систему заставило rsync / dirvish подумать, что все файлы изменились. Таким образом, вместо создания инкрементной резервной копии и просто создания жестких ссылок на уже существующие файлы, он попытался создать полную резервную копию, которая, конечно, не удалась, поскольку на жестком диске не было достаточно места для этого.

Таким образом, сообщение об ошибке было действительно правильным.

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

Глядя на оставшиеся 2% инодов, я вспомнил о корневых резервах, которые накладывает файловая система EXT. Вы можете проверить это:

1. « Зарезервированное место для root в файловой системе - почему? »
2. « Разумный размер для« зарезервированных блоков файловой системы »для дисков, не относящихся к ОС? »

Я попытался бы .tar.gz некоторые из старых резервных копий, надеясь, что это уменьшит количество используемых inode.

Я вижу, что dummzeuch находит решение своей проблемы, но на самом деле я обнаружил еще один случай, когда на диске может быть достаточно inode / свободного места и все еще отображается сообщение «на устройстве не осталось места» при попытке передачи определенных каталогов.

Это вызвано коллизиями хешей на блочных устройствах, отформатированных в файловой системе 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 млн инодов, это не должно быть проблемой. Обычно происходит около 15 миллионов инодов.

Так что это может не сильно помочь - но попробуйте ext4 на вашем устройстве резервного копирования?

Увеличьте лимит наблюдателей Inotify в sysctl:

fs.inotify.max_user_watches = 100000 

И перезагрузитесь, или сделайте sysctl -wверсию этого также.

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

Я бы посоветовал вам проверить еще пару вещей:

1. Посмотрите, не заполнен ли ваш временный каталог. Иногда он используется для промежуточного хранения и легко заполняется.
2. Проверьте, существует ли процесс, который все еще содержит дескриптор удаленного файла. Шансы менее вероятны, так как df сообщает правильный размер, но все равно это не повредит.

Я только нашел эту тему, когда искал решение своей проблемы.

На самом деле есть еще одна причина для 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).

В моем случае это означает, что мне нужно переформатировать всю файловую систему. :-(