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


36

У мене є каталог в 30 ТБ, який містить мільярди файлів, які формально є всі файли JPEG. Я видаляю кожну папку таких файлів:

sudo rm -rf bolands-mills-mhcptz

Ця команда просто працює і нічого не показує, працює вона чи ні.

Я хочу побачити, як це видалення файлів або який поточний стан команди.


19
Не відповіді: Іноді швидше створити резервну копію речей, які ви хочете зберегти, відформатувати та відновити, які ви хочете зберегти. Інші відповіді: unix.stackexchange.com/questions/37329/…
Eric Towers

2
Якщо ви просто хочете уявити про прогрес, а не знати, які конкретні файли було видалено, ви можете запустити "df / dev / sd_wever_the_drive_is".
jamesqf

11
Як у вас опинилися мільярди файлів в одному каталозі ??
Гонки легкості з Монікою

1
@MichaelHampton Але якщо файли не є окремим набором даних, це може зайняти тривалий час. (на ZFS) serverfault.com/questions/801074/…
v7d8dpo4

5
Мільярди файлів, так? Спробуйте rm -ri. Це буде весело!
OldBunny2800

Відповіді:


98

Ви можете використовувати , rm -vщоб rmнадрукувати один рядок в файл видалений. Таким чином ви бачите, що rmдійсно працює для видалення файлів. Але якщо у вас мільярди файлів, то все, що ви побачите, - rmце все ще працює. Ви не матимете уявлення, скільки файлів уже видалено і скільки залишилося.

Інструмент pvможе допомогти вам в оцінці прогресу.

http://www.ivarch.com/programs/pv.shtml

Ось як ви б викликати rmз pvз виходом , наприклад ,

$ rm -rv dirname | pv -l -s 1000 > logfile
562  0:00:07 [79,8 /s] [====================>                 ] 56% ETA 0:00:05

У цьому надуманому прикладі я сказав, pvщо є 1000файли. Результат pvпоказує, що 562 вже видалено, минувший час - 7 секунд, а оцінка для завершення - за 5 секунд.

Деякі пояснення:

  • pv -lзмушує pvрахувати нові рядки замість байтів
  • pv -s numberрозповідає, pvяка загальна сума, щоб вона могла дати вам оцінку.
  • Перенаправлення logfileна кінець призначений для чистого виведення. Інакше рядок стану від pvзмішується з результатом з rm -v. Бонус: у вас буде файл файлу, що було видалено. Але остерігайтеся, що файл вийде величезним. Ви також можете переспрямувати, /dev/nullякщо вам не потрібен журнал.

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

$ find dirname | wc -l

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

$ find dirname | pv -l | wc -l
278k 0:00:04 [56,8k/s] [     <=>                                              ]
278044

Тут йдеться про те, що для прорахування файлів 278k знадобилося 4 секунди. Точне підрахунок в кінці ( 278044) - вихід з wc -l.

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

$ rm -rv dirname | pv -l > logfile

У такий спосіб у вас немає оцінки закінчити, але принаймні ви побачите, скільки файлів уже видалено. Перенаправлення на, /dev/nullякщо вам не потрібен файл журналу.


Нітпік:

  • вам справді потрібно sudo?
  • зазвичай rm -rдостатньо для рекурсивного видалення. не потрібно rm -f.

5
Гарне використання pv, якщо припустити, що не надто дорого рахувати мільярди файлів ;-). (Це може зайняти майже стільки ж часу, скільки rmналежить виміряти!)
Стівен Кітт

7
@StephenKitt Це те, що насправді дратує мене (та багатьох інших людей) щодо утиліти файлів Windows: вона завжди , без помилок, рахує кількість та розміри файлів перед видаленням, які, якщо диск не набагато повільніше, ніж процесор, займають майже так само до тих пір, поки фактичне видалення!
wizzwizz4

@ wizzwizz4 Справді! Існує більше, ніж це, хоча IIRC - він перевіряє, що він може видалити все, перш ніж що- небудь видалити , щоб збільшити шанси на видалення "все або нічого". Багато років тому я писав драйвер файлової системи для Windows, було досить багато диваків, з якими нам довелося зіткнутися, включаючи деякі, пов’язані зі способом видалення Explorer, але я не можу згадати деталі. (Я пам’ятаю, що створення папки передбачає запис та видалення файлу в новій папці!)
Стівен Кітт

7
@StephenKitt Можливо, я помиляюся, але хіба це вузьке місце, окрім доступу до диска, термінального виходу? Я вважаю, що pvоновлює панель прогресу лише один раз на секунду, незважаючи на вклад. Отже, терміналу потрібно відображати лише один рядок, а не тону кожну секунду. pvпотрібно лише збільшити лічильник для кожного нового рядка, з яким він стикається; це повинно бути швидше, ніж робити обертання рядків, а що ні для відображення лінії в терміналі. Я думаю, що запуск, pvяк це, викликає видалення файлів швидше, ніж просто rm -rv.
JoL

1
@skywinderrm -rv dirname | pv -l -s $(find dirname | wc -l) > logfile
lesmana

28

Перевірте відповідь лесмена , це набагато краще, ніж мій - особливо останній pvприклад, який не займе набагато більше часу, ніж початковий мовчазний, rmякщо ви вкажете /dev/nullзамість logfile.

Припустимо, що ваша rmопція підтримує (можливо, це відбувається з моменту запуску Linux), ви можете запустити її у багатослівному режимі за допомогою -v:

sudo rm -rfv bolands-mills-mhcptz

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

sudo rm -rfv bolands-mills-mhcptz > rm-trace.txt

і дивіться розмір rm-trace.txt.


5
Це насправді може уповільнити видалення через те, що весь вихід генерується та надається терміналу :)
rackandboneman

2
Звичайно, це сповільниться. Запис мільярдів рядків у файл не відбувається за нульовий час.
user207421

23

Ще один варіант - спостерігати за зменшенням кількості файлів у файловій системі. В іншому терміналі запустіть:

watch  df -ih   pathname

Кількість використаних входів зменшиться в міру rmдосягнення прогресу. (Якщо файли здебільшого не мали декількох посилань, наприклад, якщо дерево було створено cp -al). Це відстежує хід видалення з точки зору кількості файлів (та каталогів). dfбез -iвідстеження з точки зору використовуваного простору.

Ви також можете запустити, iostat -x 4щоб побачити операції вводу / виводу за секунду (як і кіБ / с, але це не дуже актуально для чистих метаданих вводу / виводу).


Якщо вам цікаво, над якими файлами rmзараз працює, ви можете приєднати straceдо нього та спостерігати за тим, як unlink()(і getdents) системні дзвінки заїжджають на ваш термінал. напр sudo strace -p $(pidof rm). Ви можете ^cрозтягнути шнур, rmне перебиваючи його.

Я забуваю, якщо rm -rзмінити каталог в дерево, яке воно видаляє; якби ви так могли поглянути /proc/<PID>/cwd. Його /proc/<PID>/fdміць часто каталог Fd відкритою, так що ви могли б дивитися на це , щоб побачити , що ваш rmпроцес в даний час розглядає.


2
df -ihце справді приємний дешевий спосіб спостерігати за rmпрогресом.
Стівен Кітт

BTW, це не працює на BTRFS, де кількість використаних inode завжди дорівнює нулю. :( Те саме для FAT32, але у вас, ймовірно, немає мільярдів файлів на вашому /bootсистемному розділі EFI.
Пітер Кордес

4

Хоча вищезазначені відповіді всі використовують rm, rmнасправді може бути досить повільним при видаленні великої кількості файлів, як я нещодавно зауважував, коли витягування ~ 100K файлів з архіву .tar фактично займало менше часу, ніж їх видалення. Хоча це насправді не відповідає на задане вами питання, кращим рішенням вашої проблеми може бути використання іншого методу для видалення файлів, наприклад, одного з актуальних відповідей на це питання .

Мій особистий улюблений метод - це використовувати rsync -a --delete. Я вважаю, що цей метод працює досить швидко, що варто простоти у використанні над найбільш схваленою відповіддю на це питання , в якій автор написав програму C, яку вам потрібно було б скласти. (Зверніть увагу, що це виведе кожен файл, який обробляється до stdout, приблизно так rm -rv; це може уповільнити процес на дивовижне кількість. Якщо ви не хочете цього виводу, використовуйте rsync -aq --deleteабо перенаправляйте вихід на файл.

Автор цієї відповіді каже:

Тепер програма (в моїй системі) видалить 1000000 файлів за 43 секунди. Найближчою програмою до цього був rsync -a --delete, який зайняв 60 секунд (що також виконує видалення в порядку, але не виконує ефективного пошуку каталогу).

Я виявив, що це досить добре для моїх цілей. Також важливо важливий з цього відповіді, принаймні, якщо ви використовуєте ext4:

Для попереднього роздуму слід видалити пошкоджений каталог і переробити його після. Каталоги лише коли-небудь збільшуються в розмірі і можуть залишатися погано ефективними навіть з кількома файлами всередині через розмір каталогу.


так, я б очікував rmі / або find --deleteбути ефективним. Цікавий момент щодо видалення в порядку сортування, щоб уникнути балансування b-дерева під час видалення. Не впевнений, наскільки це стосується інших файлових систем. XFS також не чудово з мільйонами файлів у каталозі. IDK про BTRFS, але я маю враження, що це може бути добре для подібних речей.
Пітер Кордес

Чи не залежить ця друга цитата від типу файлової системи ...
Menasheh

@Menasheh Добре, я змінив це у своїй відповіді.
Hitechcomputergeek

3

Одне, що ви можете зробити, - це запустити rmпроцес у фоновому режимі (без виводу, щоб він не сповільнився), а потім, відстежуйте його на передньому плані за допомогою простої (а) команди:

pax> ( D=/path/to/dir ; rm -rf $D & while true ; do
...>   if [[ -d $D ]] ; then
...>     echo "$(find $D | wc -l) items left"
...>   else
...>     echo "No items left"
...>     break
...>   fi
...>   sleep 5
...> done )

27912 items left
224 items left
No items left

pax> _

find/wcКомбо може бути замінений будь-яким інструментом , здатним дати вам одиниці , які ви хочете.


(а) Ну, порівняно просто, порівняно з, скажімо, ядерною фізикою, гіпотезою Рімана, або що купити дружині на Xmas :-)


0

Певний час тому я щось писав, щоб надрукувати швидкість, яку друкували рядки. Ви можете запустити, rm -rfv | ./counterі він буде друкувати рядки за секунду / хв. Хоча це і не є прямим прогресом, він дасть вам деякий відгук про швидкість прогресу, можливо, rmблукав у мережевій файловій системі чи подібному, можливо?

Посилання на код знаходиться тут:

http://www.usenix.org.uk/code/counter-0.01.tar.gz

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.