Чи є якась інша причина, що на пристрої не залишилося місця?

Я використовую Dirvish на серверній системі Ubuntu для резервного копіювання hd на зовнішній привід 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 порожній

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

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 деякі старіші резервні копії, сподіваючись, що це зменшить кількість вживаних входів.

Я бачу, що 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М введення, це не повинно бути проблемою. Зазвичай трапляється близько 15М входів.

Тож це може не допомогти - але спробувати ext4 на своєму резервному пристрої?

Збільшити межу спостереження за спостереженнями в 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).

У моєму випадку це означає, що мені доведеться переформатувати всю файлову систему. :-(