Як виправити помилки "Не залишилось місця на пристрої" під час роботи телевізора, коли у пристрою багато місця?

• Ubuntu 14.04 на робочому столі
• Джерело джерела: / dev / sda1: 5TB ext4 одномісний
  об'єм диска
• Цільовий об'єм: / dev / mapper / archive-lvarchive: raid6 (mdadm) Об'єм 18TB з
  розділом lvm та ext4

Перемістити приблизно 15 мільйонів файлів, а деякі можуть бути дублікатами (я не хочу перезаписувати дублікати).

Використовувана команда (з вихідного каталогу):

ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}

Це триває вже кілька днів, як очікувалося, але я отримую помилку у збільшенні частоти. Коли він запустився, цільовий накопичувач був заповнений приблизно на 70%, зараз його близько 90%. Раніше приблизно 1/200 кроків було б станом та помилками, зараз це приблизно 1/5. Жоден з файлів не перевищує 100 Мб, більшість - близько 100 Кб

Деякі відомості:

$ df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/sdb3                      155G  5.5G  142G   4% /
none                           4.0K     0  4.0K   0% /sys/fs/cgroup
udev                           3.9G  4.0K  3.9G   1% /dev
tmpfs                          797M  2.9M  794M   1% /run
none                           5.0M  4.0K  5.0M   1% /run/lock
none                           3.9G     0  3.9G   0% /run/shm
none                           100M     0  100M   0% /run/user
/dev/sdb1                       19G   78M   18G   1% /boot
/dev/mapper/archive-lvarchive   18T   15T  1.8T  90% /mnt/archive
/dev/sda1                      4.6T  1.1T  3.3T  25% /mnt/tmp

$ df -i
Filesystem                       Inodes    IUsed     IFree IUse% Mounted on
/dev/sdb3                      10297344   222248  10075096    3% /
none                            1019711        4   1019707    1% /sys/fs/cgroup
udev                            1016768      500   1016268    1% /dev
tmpfs                           1019711     1022   1018689    1% /run
none                            1019711        5   1019706    1% /run/lock
none                            1019711        1   1019710    1% /run/shm
none                            1019711        2   1019709    1% /run/user
/dev/sdb1                       4940000      582   4939418    1% /boot
/dev/mapper/archive-lvarchive 289966080 44899541 245066539   16% /mnt/archive
/dev/sda1                     152621056  5391544 147229512    4% /mnt/tmp

Ось мій результат:

mv -n 747265521.pdf /mnt/archive/targetDir/747265521.pdf 
mv -n 61078318.pdf /mnt/archive/targetDir/61078318.pdf 
mv -n 709099107.pdf /mnt/archive/targetDir/709099107.pdf 
mv -n 75286077.pdf /mnt/archive/targetDir/75286077.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/75286077.pdf’: No space left on device
mv -n 796522548.pdf /mnt/archive/targetDir/796522548.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/796522548.pdf’: No space left on device
mv -n 685163563.pdf /mnt/archive/targetDir/685163563.pdf 
mv -n 701433025.pdf /mnt/archive/targetDir/701433025.pd

Я знайшов багато публікацій про цю помилку, але прогноз не відповідає. Такі проблеми, як "ваш накопичувач насправді повний" або "у вас закінчилося введення" або навіть "ваш / завантажувальний об'єм повний". Здебільшого, вони мають справу з стороннім програмним забезпеченням, яке спричиняє проблеми через те, як вони обробляють файли, і всі вони постійні, тобто КОЖНЕ переміщення не вдається.

Спасибі.

EDIT: ось зразок файлу не вдався і вдалося:

FAILED (все ще на вихідному диску)

ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf

УСПЕХ (на цільовому обсязі)

ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf

Крім того, хоча не всі файли виходять з ладу, файл, який виходить з ладу, ЗАВЖДИ не працює. Якщо я повторюю це знову і знову, це буде послідовно.

EDIT: Деякі додаткові команди на запит від @mjturner

$ ls -ld /mnt/archive/targetDir
drwxrwxr-x 2 myUser myUser 1064583168 Aug 10 05:07 /mnt/archive/targetDir

$ tune2fs -l /dev/mapper/archive-lvarchive
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/archive
Filesystem UUID:          af7e7b38-f12a-498b-b127-0ccd29459376
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              289966080
Block count:              4639456256
Reserved block count:     231972812
Free blocks:              1274786115
Free inodes:              256343444
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        512
Flex block group size:    16
Filesystem created:       Thu Jun 25 12:05:12 2015
Last mount time:          Mon Aug  3 18:49:29 2015
Last write time:          Mon Aug  3 18:49:29 2015
Mount count:              8
Maximum mount count:      -1
Last checked:             Thu Jun 25 12:05:12 2015
Check interval:           0 (<none>)
Lifetime writes:          24 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3ea3edc4-7638-45cd-8db8-36ab3669e868
Journal backup:           inode blocks

$ tune2fs -l /dev/sda1
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/tmp
Filesystem UUID:          10df1bea-64fc-468e-8ea0-10f3a4cb9a79
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              152621056
Block count:              1220942336
Reserved block count:     61047116
Free blocks:              367343926
Free inodes:              135953194
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      732
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
Flex block group size:    16
Filesystem created:       Thu Jul 23 13:54:13 2015
Last mount time:          Tue Aug  4 04:35:06 2015
Last write time:          Tue Aug  4 04:35:06 2015
Mount count:              3
Maximum mount count:      -1
Last checked:             Thu Jul 23 13:54:13 2015
Check interval:           0 (<none>)
Lifetime writes:          150 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a266fec5-bc86-402b-9fa0-61e2ad9b5b50
Journal backup:           inode blocks

Помилка в реалізації функції ext4, dir_indexяку ви використовуєте у вашій цільовій файловій системі.

Рішення: відтворити файл файлу без dir_index. Або відключити функцію, використовуючи tune2fs (потрібна деяка обережність, див. Пов’язане посилання Novell SuSE 10/11: вимкнення індексації H-Tree у файловій системі ext3, яка, хоча і стосується ext3, може знадобитися аналогічною обережністю.

(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)

• ext4: таємничі помилки "На пристрої не залишилося місця"

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

......

У ext4 є можливість хеш-файлів його вмісту. Це підвищує продуктивність, але має "невелику" проблему: ext4 не збільшує хеш-пам’яті, коли він починає заповнюватися. Замість цього він повертає -ENOSPC або "на пристрої не залишається місця".

Пропозиції щодо кращого варіанту вибору для зберігання маси невеликих файлів:

Якщо ви використовуєте файлову систему як сховище об'єктів, вам варто поглянути на використання файлової системи, яка спеціалізується на цьому, можливо, на шкоду іншим характеристикам. Швидкий пошук у Google знайшов Ceph , який, як видається, є відкритим кодом, і його можна встановити як файлову систему POSIX, але також доступ до нього можна отримати з іншими API. Я не знаю, чи варто це використовувати на одному хості, не скориставшись реплікацією.

Ще одна система зберігання об'єктів - Swift OpenStack . Документи дизайну говорять, що він зберігає кожен об'єкт як окремий файл, з метаданими у xattrs . Ось стаття про це. Їх розгортання гід каже , що вони знайшли XFS дали найкращу продуктивність для зберігання об'єктів. Тож хоча завантаженість не є найкращою для XFS, вона, мабуть, була кращою, ніж конкуренти, коли RackSpace тестував речі. Можливо, Swift надає перевагу XFS, оскільки XFS має гарну / швидку підтримку розширених атрибутів. Можливо, ext3 / ext4 зробить добре на одних дисках як резервний файл об'єкта, якщо зайві метадані не потрібні (або якщо вони зберігаються всередині двійкового файлу).

Swift робить реплікацію / балансування навантаження для вас і пропонує вам надати їй файлові системи, створені на сирому диску, а не RAID . Він вказує на те, що його завантаженість по суті є найгіршим випадком для RAID5 (що має сенс, якщо ми говоримо про навантаження з записом невеликих файлів. XFS, як правило, не дуже упаковує їх головою до хвоста, тому ви не get full-stripe write, і RAID5 повинен виконати кілька читання, щоб оновити смугу паритету. Документи Swift також говорять про використання 100 розділів на диск. Я припускаю, що це термін Swift і не говорить про створення 100 різних файлових систем XFS на кожній SATA диск.

Запуск окремого XFS для кожного диска насправді величезна різниця . Замість однієї гігантської карти вільного введення кожен диск матиме окремий XFS з окремими вільними списками. Крім того, це дозволяє уникнути штрафу RAID5 за невеликі записи.

Якщо у вас вже створено програмне забезпечення для використання файлової системи безпосередньо для зберігання об’єктів, а не для того, щоб переглядати щось на зразок Swift для обробки реплікації / балансування навантаження, то ви можете принаймні уникнути наявності всіх ваших файлів в одному каталозі. (Я не бачив, як документи Swift говорять про те, як вони розкладають свої файли в декілька каталогів, але я впевнений, що вони роблять.)

Практично з будь-якою нормальною файловою системою це допоможе використовувати структуру типу

1234/5678   # nested medium-size directories instead of
./12345678   # one giant directory

Напевно, приблизно 10 К записів є розумним, тому прийняття добре розподілених 4 символів ваших імен об'єктів та використання їх як каталогів - це просте рішення. Це не повинно бути дуже добре збалансованим. Непарний каталог 100k, мабуть, не буде помітною проблемою, і також не буде порожніх каталогів.

XFS не ідеально підходить для величезної маси невеликих файлів. Він робить все, що може, але більш оптимізований для потокового запису великих файлів. Хоча це загалом добре для загального використання. Він не має ENOSPCзіткнень в індексації каталогу (AFAIK), і може обробляти один каталог з мільйонами записів. (Але все ж краще використовувати принаймні однорівневе дерево.)

У Дейва Чіннера були зауваження щодо продуктивності XFS, коли було виділено величезну кількість вводів , що призвело до повільних touchрезультатів. Пошук вільного inode для виділення починає забирати більше процесорного часу, оскільки растровий малюнок вільного inode стає фрагментарним. Зауважте, що це не проблема однієї великої каталогів проти кількох каталогів, а скоріше проблема багатьох використаних входів у всій файловій системі. Розщеплення файлів на декілька каталогів допомагає з деякими проблемами, як, наприклад, що ext4 задихнувся в ОП, але не з проблемою цілого диска відстеження вільного місця. У цьому допомагає окрема файлова система Swift на диск, порівняно з гігантським XFS на RAID5.

Я не знаю, чи добре це btrfs в цьому, але я думаю, що це може бути. Я думаю, що Facebook найчастіше працює зі своїм головним розробником. : P Деякі показники, які я бачив, такі речі, як видалення джерела ядра Linux, показують, що btrfs добре справляється.

Я знаю, що рейзерфи були оптимізовані для цього випадку, але це ледве, якщо взагалі не підтримується. Я дійсно не можу рекомендувати йти з reiser4. Це може бути цікаво експериментувати. Але це далеко не найменший надійний вибір. Я також бачив повідомлення про зниження продуктивності на застарілому reiserFS, і немає хорошого інструменту дефрагментації. (Google filesystem millions of small filesі перегляньте деякі з існуючих відповідей на stackexchange.)

Напевно, мені чогось не вистачає, тому остаточна рекомендація: запитайте про це на сервері за замовчуванням! Якби мені довелося щось вибрати прямо зараз, я б сказав, спробуйте BTRFS, але переконайтесь, що у вас є резервні копії. (особливо, якщо ви використовуєте вбудований BTRFS з декількома надмірностями диска, замість того, щоб запускати його поверх RAID. Переваги продуктивності можуть бути великими, оскільки невеликі файли - це погані новини для RAID5, якщо це не завантаженість в основному.)

Для цього питання нижче - що я вирішив (вам може знадобитися доступ до судо для наступних кроків):

1. Використовуваний простір Inodes становив 100%, який можна отримати за допомогою команди нижче

   df -i /

Вкладення файлової системи IUsed IFree IUse% Встановлено

/dev/xvda1            524288   524288  o     100% /

2. Потрібно звільнити iNoted, отже, потрібно знайти файли, які мають тут кількість i вузлів, використовуючи команду нижче:

Спробуйте дізнатися, чи це проблема з inodes із:

df -ih

Спробуйте знайти кореневі папки з великою кількістю утворень:

for i in /*; do echo $i; find $i |wc -l; done

Спробуйте знайти конкретні папки:

for i in /src/*; do echo $i; find $i |wc -l; done

3. тепер ми зробили нуль до папки з великою кількістю файлів у ній. Запустіть команди нижче, щоб уникнути помилок (у моєму випадку фактична папка була / var / spool / clientmqueue):

find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +