Видаліть 10M + файлів із ZFS, ефективно

Я написав помилкову програму, яка випадково створила близько 30М файлів під / tmp. (Помилка була введена кілька тижнів тому, і вона створювала пару підкаталогів в секунду.) Я міг перейменувати / tmp в / tmp2, і тепер мені потрібно видалити файли. Система FreeBSD 10, коренева файлова система - zfs.

Тим часом один із приводів у дзеркалі пішов не так, і я його замінив. У накопичувача є два 120 ГБ SSD-дисків.

Ось питання: заміна жорсткого диска та повторне ремонту всього масиву зайняли менше години. Видалення файлів / tmp2 - інша історія. Я написав іншу програму для видалення файлів, і вона може видалити лише 30-70 підкаталогів за секунду. Щоб видалити всі файли, знадобиться 2-4 дні.

Як можливо, що повторне переміщення всього масиву займає годину, але видалення з диска займає 4 дні? Чому в мене такі погані показники? 70 видалень в секунду здається дуже поганою роботою.

Я міг би видалити inode for / tmp2 вручну, але це не звільнить простір, правда?

Чи може це бути проблема з zfs, жорсткими дисками чи що?

Видалити в ZFS дорого. Тим більше, що у вас увімкнено дедупликацію у файловій системі (оскільки розмежування виведених файлів коштує дорого). Знімки також можуть ускладнити питання.

Можливо, вам буде краще видалити /tmp каталог замість даних, що містяться в ньому.

Якщо /tmpце файлова система ZFS, видаліть її та створіть заново.

Як можливо, що повторне переміщення всього масиву займає годину, але видалення з диска займає 4 дні?

Розгляньте офісну будівлю.

Видалення всіх комп’ютерів та меблів та кріплення з усіх офісів на всіх поверхах займає багато часу, але офіси негайно використовуються іншим клієнтом.

Зруйнувати все будівлю з гексогеном це набагато швидше, але наступний клієнт цілком ймовірно, скаржиться , як протяг місця є.

Тут відбувається ряд речей.

По-перше, всі сучасні дискові технології оптимізовані для масових передач. Якщо вам потрібно перемістити 100 Мб даних, вони зроблять це набагато швидше, якщо вони будуть в одному суміжному блоці, а не розкидані по всьому місцю. Тут багато допомагають SSD-диски, але навіть вони віддають перевагу даним у суміжних блоках.

По-друге, resilvering є досить оптимальним, що стосується операцій з дисками. Ви читаєте величезний суміжний фрагмент даних з одного диска, робите кілька швидких операційних процесорів на ньому, а потім переписуєте їх в інший великий суміжний фрагмент на інший диск. Якщо живлення вийде з ладу частково, нічого страшного - ви просто проігноруєте будь-які дані з поганими контрольними сумами та продовжуватиметесь, як це нормально.

По-третє, видалення файлу відбувається дуже повільно . ZFS особливо поганий, але практично всі файлові системи видаляють повільно. Вони повинні модифікувати велику кількість різних фрагментів даних на диску і час їх коректно (тобто чекати), щоб файлова система не була пошкоджена при відключенні живлення.

Як можливо, що повторне переміщення всього масиву займає годину, але видалення з диска займає 4 дні?

Resilvering - це те, на чому диски дійсно швидкі, а видалення - це те, на чому диски повільні. На мегабайт диска вам потрібно зробити лише трохи ресилліверінгу. У цьому просторі може бути тисяча файлів, які потрібно видалити.

70 видалень в секунду здається дуже поганою роботою

Це залежить. Я не здивувався б цьому. Ви не згадали, який тип SSD ви використовуєте. Сучасні SSD-накопичувачі Intel та Samsung досить хороші в такому режимі роботи (читати-змінювати-писати) і працюватимуть краще. Дешевші / старі SSD (наприклад, Corsair) будуть повільними. Тут визначальним є число операцій вводу / виводу в секунду (IOPS).

ZFS є особливо повільно видалити речі. Зазвичай він виконує видалення у фоновому режимі, щоб ви не побачили затримки. Якщо ви робите величезну кількість з них, вони не можуть цього приховати і повинні затримати вас.

Додаток: чому видалення відбувається повільно?

• Для видалення файла потрібно виконати кілька кроків. Метадані файлу повинні бути позначені як "видалені", і з часом вони повинні бути відтворені, щоб простір можна було повторно використовувати. ZFS - це "файлова система, структурована журналом", яка найкраще працює, якщо ви коли-небудь створюєте речі, ніколи не видаляйте їх. Структура журналу означає, що якщо ви щось видалите, у журналі є пробіл, і тому інші дані повинні бути переставлені (дефрагментовані), щоб заповнити проміжок. Це невидимо для користувача, але, як правило, повільно.
• Зміни повинні бути внесені таким чином, що якщо живлення не відбудеться частково, файлова система залишатиметься послідовною. Часто це означає чекати, поки диск підтвердить, що дані дійсно є на носії; для SSD, це може зайняти багато часу (сотні мілісекунд). Чистий ефект від цього полягає в тому, що існує набагато більше бухгалтерій (тобто операцій дискового вводу / виводу).
• Всі зміни невеликі. Замість читання, запису та стирання цілих блоків флеш (або циліндрів для магнітного диска) вам потрібно трохи змінити один. Для цього обладнання потрібно прочитати в цілому блоці або циліндрі, змінити його в пам'яті, а потім знову виписати на носій. Це займає тривалий час.

Як можливо, що повторне переміщення всього масиву займає годину, але видалення з диска займає 4 дні?

Це можливо, оскільки дві операції працюють на різних шарах стека файлової системи. Resilvering може працювати на низькому рівні і фактично не потрібно дивитись на окремі файли, копіюючи великі шматки даних за один раз.

Чому в мене такі погані показники? 70 видалень в секунду здається дуже поганою роботою.

Це мусить зробити багато бухгалтерії ...

Я міг би видалити inode for / tmp2 вручну, але це не звільнить простір, правда?

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

Чи може це бути проблема з zfs, жорсткими дисками чи що?

Це zfs scrubщось говорить?

Видалення великої кількості файлів ніколи насправді не є швидкою операцією.

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

Навіть без особливостей, представлених ZFS, видалення 30 мільйонів файлів зазвичай означає понад сто мільйонів окремих операцій вводу / виводу. Це буде займати багато часу , навіть з швидким SSD. Як уже згадували інші, конструкція ZFS додатково ускладнює це питання.

Ян Хоусон дає хорошу відповідь на те, чому це повільно.

Якщо ви видаляєте файли паралельно, ви можете побачити збільшення швидкості внаслідок видалення, можливо, використовуйте одні й ті ж блоки, і таким чином можна зберегти повторне написання одного і того ж блоку багато разів.

Тому спробуйте:

find /tmp -print0 | parallel -j100 -0 -n100 rm

і подивіться, чи працює це краще, ніж ваші 70 делетів за секунду.

Дуже просто, якщо ви інвертуєте своє мислення.

1. Отримайте другий привід (у вас, здається, це вже є)

2. Скопіюйте все з диска A на диск B з rsync, виключаючи каталог / tmp. Rsync буде повільніше, ніж блокова копія.

3. Перезавантажте, використовуючи диск B як новий об'єм завантаження

4. Привід реформату А.

Це також дефрагментує ваш накопичувач і дасть вам новий каталог (прекрасно, дефрагментація не настільки важлива для SSD, але лінеаризація ваших файлів ніколи нічого не зашкодить)

У вас 30 мільйонів записів у несортованому списку. Ви скануєте список на запис, який ви хочете видалити, і ви видаляєте його. Зараз у вас у списку несортованих лише 29 999 999 записів. Якщо вони всі в / tmp, чому б не просто перезавантажити?

Відредаговано для відображення інформації в коментарях: Повідомлення про проблему: Видалення більшості, але не всіх , 30M + неправильно створених файлів у / tmp займає багато часу.
Проблема 1) Найкращий спосіб видалити велику кількість непотрібних файлів з / tmp.
Проблема 2) Розуміння, чому так повільно видаляти файли.

Рішення 1) - / tmp скидається до порожнього під час завантаження більшістю * nix розподілів. FreeBSD, однак, не є одним із них.
Крок 1 - скопіюйте цікаві файли десь в іншому місці.
Крок 2 - Як корінь

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Крок 3 - перезавантажте.
Крок 4 - поверніть clear_tmp_enable назад на "Ні".
Небажані файли відпадають, оскільки ZFS у FreeBSD має таку особливість, що "Знищення набору даних набагато швидше, ніж видалення всіх файлів, що знаходяться на наборі даних, оскільки це не передбачає сканування всіх файлів та оновлення всіх відповідних метаданих. " тому все, що він повинен робити під час завантаження, скидає метадані для набору даних / tmp. Це дуже швидко.

Рішення 2) Чому це так повільно? ZFS - це чудова файлова система, яка включає такі функції, як постійний доступ до часових каталогів. Це добре працює, якщо ви знаєте, чим займаєтесь, але дані свідчать про те, що ОП не є експертом ZFS. ОП не вказала, як вони намагалися видалити файли, але, напевно, я б сказав, що вони використовували варіант "знайти regex -exec rm {} \;". Це добре працює з невеликою кількістю, але не збільшує масштаб, тому що триває три послідовні операції 1) отримуйте список доступних файлів (повертає 30 мільйонів файлів у хеш-порядку), 2) використовуйте регулярний вибір, щоб вибрати наступний файл для видалення, 3 ) скажіть ОС знайти та видалити цей файл зі списку 30 мільйонів. Навіть якщо ZFS повертає список з пам'яті, і якщо 'find' кешує його, регулярний вираз ще повинен визначити наступний файл, який обробляється зі списку, а потім сказати ОС оновити свої метадані, щоб відобразити цю зміну, а потім оновити список, щоб він не оброблявся знову.