Xóa hàng tỷ tệp từ một thư mục trong khi vẫn thấy tiến trình


36

Tôi có một thư mục 30 TB có hàng tỷ tệp trong đó chính thức là tất cả các tệp JPEG. Tôi đang xóa từng thư mục của các tập tin như thế này:

sudo rm -rf bolands-mills-mhcptz

Lệnh này chỉ chạy và không hiển thị bất cứ điều gì cho dù nó hoạt động hay không.

Tôi muốn xem vì nó đang xóa các tập tin hoặc trạng thái hiện tại của lệnh là gì.


19
Không trả lời: Đôi khi, sao lưu nhanh hơn những thứ bạn muốn giữ, định dạng và khôi phục những thứ bạn muốn giữ. Các câu trả lời khác: unix.stackexchange.com/questions/37329/ trộm
Tháp Eric

2
Nếu bạn chỉ muốn một ý tưởng về tiến trình, thay vì biết những tập tin cụ thể nào đã bị xóa, bạn có thể chạy "df / dev / sd_whthing_the_drive_is".
jamesqf

11
Làm thế nào bạn kết thúc với hàng tỷ tập tin trong một thư mục ??
Cuộc đua nhẹ nhàng với Monica

1
@MichaelHampton Nhưng nếu các tệp không phải là một tập dữ liệu riêng biệt, có thể mất nhiều thời gian. (trên ZFS) serverfault.com/questions/801074/
Khắc

5
Hàng tỷ tập tin, phải không? Hãy thử rm -ri. Nó sẽ rất vui!
OldBunny2800

Câu trả lời:


98

Bạn có thể sử dụng rm -vđể rmin một dòng trên mỗi tệp. Bằng cách này bạn có thể thấy rằng rmthực sự đang làm việc để xóa các tập tin. Nhưng nếu bạn có hàng tỷ tệp thì tất cả những gì bạn sẽ thấy là nó rmvẫn hoạt động. Bạn sẽ không biết có bao nhiêu tệp đã bị xóa và còn lại bao nhiêu.

Công cụ này pvcó thể giúp bạn ước tính tiến độ.

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

Đây là cách bạn sẽ gọi rmvới pvđầu ra ví dụ

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

Trong ví dụ giả định này, tôi đã nói pvrằng có 1000các tệp. Đầu ra từ pvcho thấy 562 đã bị xóa, thời gian trôi qua là 7 giây và ước tính để hoàn thành là trong 5 giây.

Một số giải thích:

  • pv -llàm cho pvviệc đếm theo dòng mới thay vì byte
  • pv -s numbercho biết pvtổng số là gì để nó có thể cung cấp cho bạn một ước tính.
  • Chuyển hướng đến logfilecuối là cho đầu ra sạch. Nếu không, dòng trạng thái từ pvđược trộn lẫn với đầu ra từ rm -v. Phần thưởng: bạn sẽ có một logfile về những gì đã bị xóa. Nhưng hãy cẩn thận các tập tin sẽ nhận được rất lớn. Bạn cũng có thể chuyển hướng đến /dev/nullnếu bạn không cần một bản ghi.

Để có được số lượng tệp bạn có thể sử dụng lệnh này:

$ find dirname | wc -l

Điều này cũng có thể mất nhiều thời gian nếu có hàng tỷ tệp. Bạn cũng có thể sử dụng pvở đây để xem nó đã đếm được bao nhiêu

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

Ở đây nó nói rằng phải mất 4 giây để đếm được 278k tệp. Số đếm chính xác ở cuối ( 278044) là đầu ra từ wc -l.

Nếu bạn không muốn chờ đếm thì bạn có thể đoán số lượng tệp hoặc sử dụng pvmà không cần ước tính:

$ rm -rv dirname | pv -l > logfile

Như thế này bạn sẽ không có ước tính để kết thúc nhưng ít nhất bạn sẽ thấy có bao nhiêu tệp đã bị xóa. Chuyển hướng đến /dev/nullnếu bạn không cần logfile.


Nitpick:

  • bạn có thực sự cần sudokhông
  • thường rm -rlà đủ để xóa đệ quy. không cần cho rm -f.

5
Sử dụng tốt pv, giả sử nó không quá đắt để đếm hàng tỷ tệp ;-). (Nó có thể mất gần như nhiều thời gian rmđể đo lường!)
Stephen Kitt

7
@StephenKitt Đây là những gì thực sự làm phiền tôi (và nhiều người khác) về các tiện ích tập tin Windows: nó luôn , chắc chắn thế, đếm số lượng và kích thước của các tập tin trước khi xóa mà, trừ khi ổ đĩa là nhiều chậm hơn so với bộ vi xử lý, mất gần như miễn là xóa thực tế!
wizzwizz4

@ wizzwizz4 Thật vậy! Có nhiều thứ hơn thế mặc dù IIRC - nó kiểm tra rằng nó có thể xóa mọi thứ trước khi xóa bất cứ thứ gì , để tăng cơ hội xóa là "tất cả hoặc không có gì". Cách đây nhiều năm, tôi đã viết một trình điều khiển hệ thống tập tin cho Windows, có khá nhiều điều kỳ lạ mà chúng tôi phải giải quyết, bao gồm một số vấn đề liên quan đến cách Explorer tiến hành xóa, nhưng tôi không thể nhớ chi tiết. (Tôi nhớ rằng việc tạo thư mục liên quan đến việc viết và xóa một tệp trong thư mục mới!)
Stephen Kitt

7
@StephenKitt Có thể tôi nhầm, nhưng không phải là nút cổ chai, bên cạnh việc truy cập đĩa, đầu ra của thiết bị đầu cuối? Tôi tin rằng pvlàm mới thanh tiến trình chỉ một lần mỗi giây, mặc dù đầu vào của nó. Vì vậy, thiết bị đầu cuối chỉ cần hiển thị một dòng thay vì một tấn mỗi giây. pvchỉ cần tăng một bộ đếm cho mỗi dòng mới mà nó gặp phải; điều đó phải nhanh hơn so với thực hiện ngắt dòng và không có gì để hiển thị một dòng trong một thiết bị đầu cuối. Tôi nghĩ rằng chạy với pvnhư thế này là nguyên nhân khiến việc xóa tệp nhanh hơn đơn giản rm -rv.
JoL

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

28

Kiểm tra câu trả lời của lesmana , nó tốt hơn nhiều so với của tôi - đặc biệt là pvví dụ cuối cùng , sẽ không mất nhiều thời gian hơn so với im lặng ban đầu rmnếu bạn chỉ định /dev/nullthay vì logfile.

Giả sử rmhỗ trợ của bạn tùy chọn (có thể là do bạn đang chạy Linux), bạn có thể chạy nó ở chế độ dài dòng với -v:

sudo rm -rfv bolands-mills-mhcptz

Như đã được chỉ ra bởi một số người bình luận, điều này có thể rất chậm vì số lượng đầu ra được tạo ra và hiển thị bởi thiết bị đầu cuối. Thay vào đó, bạn có thể chuyển hướng đầu ra thành một tệp:

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

và xem kích thước của rm-trace.txt.


5
Điều này thực sự có thể làm chậm quá trình xóa vì tất cả đầu ra được tạo và kết xuất tới một thiết bị đầu cuối :)
rackandboneman

2
Tất nhiên nó sẽ chậm lại. Viết hàng tỷ dòng vào một tệp không xảy ra trong thời gian không.
dùng207421

23

Một tùy chọn khác là xem số lượng tập tin trên hệ thống tập tin giảm. Trong một thiết bị đầu cuối khác, chạy:

watch  df -ih   pathname

Số lượng inodes được sử dụng sẽ giảm khi rmtiến bộ. (Trừ khi các tệp chủ yếu có nhiều liên kết, ví dụ: nếu cây được tạo bằng cp -al). Điều này theo dõi tiến trình xóa theo số lượng tệp (và thư mục). dfmà không -itheo dõi về mặt không gian sử dụng.

Bạn cũng có thể chạy iostat -x 4để xem các hoạt động I / O mỗi giây (cũng như kiB / s, nhưng điều đó không liên quan lắm đối với I / O siêu dữ liệu thuần túy).


Nếu bạn tò mò về những tập tin rmhiện đang làm việc, bạn có thể đính kèm stracevào nó và xem như các unlink()cuộc gọi hệ thống (và getdents) phun ra trên thiết bị đầu cuối của bạn. ví dụ sudo strace -p $(pidof rm). Bạn có thể ^cbước đi để tách ra rmmà không làm gián đoạn nó.

Tôi quên nếu rm -rthay đổi thư mục vào cây, nó sẽ xóa; nếu có thì bạn có thể nhìn vào /proc/<PID>/cwd. Nó /proc/<PID>/fdthường có thể có một thư mục fd mở, vì vậy bạn có thể nhìn vào đó để xem rmquá trình của bạn hiện đang xem gì .


2
df -ihthực sự là một cách tốt đẹp để xem rmtiến độ.
Stephen Kitt

BTW, điều này không hoạt động trên BTRFS, trong đó số lượng inode được sử dụng luôn bằng không. :( Tương tự với FAT32, nhưng có lẽ bạn không có hàng tỷ tệp trên /bootphân vùng hệ thống EFI của mình .
Peter Cordes

4

Mặc dù tất cả các câu trả lời trên đều sử dụng rm, nhưng rmthực sự có thể khá chậm trong việc xóa một số lượng lớn tệp, như tôi đã quan sát gần đây khi trích xuất ~ 100K tệp từ kho lưu trữ .tar thực sự tốn ít thời gian hơn so với xóa chúng. Mặc dù điều này không thực sự trả lời câu hỏi bạn đã hỏi, một giải pháp tốt hơn cho vấn đề của bạn có thể là sử dụng một phương pháp khác để xóa các tệp của bạn, chẳng hạn như một trong những câu trả lời được nêu lên cho câu hỏi này .

Phương pháp yêu thích cá nhân của tôi là sử dụng rsync -a --delete. Tôi thấy rằng phương pháp này thực hiện đủ nhanh đến mức đáng để sử dụng dễ dàng hơn câu trả lời được đánh giá cao nhất cho câu hỏi đó , trong đó tác giả đã viết một chương trình C mà bạn sẽ cần biên dịch. (Lưu ý rằng điều này sẽ xuất ra mọi tệp đang được xử lý thành thiết bị xuất chuẩn, giống như rm -rv; điều này có thể làm chậm quá trình một cách đáng ngạc nhiên. Nếu bạn không muốn đầu ra này, hãy sử dụng rsync -aq --deletehoặc chuyển hướng đầu ra sang tệp thay thế.)

Tác giả của câu trả lời đó nói:

Chương trình bây giờ (trên hệ thống của tôi) sẽ xóa 1000000 tệp trong 43 giây. Chương trình gần nhất với điều này là rsync -a --delete mất 60 giây (cũng xóa theo thứ tự, nhưng không thực hiện tra cứu thư mục hiệu quả).

Tôi đã thấy rằng điều này là đủ tốt cho mục đích của tôi. Cũng có khả năng quan trọng từ câu trả lời đó, ít nhất là nếu bạn đang sử dụng ext4:

Như đã biết trước, người ta nên xóa thư mục bị ảnh hưởng và làm lại sau. Các thư mục chỉ tăng kích thước và có thể vẫn hoạt động kém ngay cả với một vài tệp bên trong do kích thước của thư mục.


huh, tôi đã mong đợi rmvà / hoặc find --deletesẽ có hiệu quả. Điểm thú vị về việc xóa theo thứ tự để tránh cân bằng b-cây trong khi xóa. Không chắc chắn bao nhiêu trong số đó áp dụng cho các hệ thống tập tin khác. XFS cũng không tuyệt vời với hàng triệu tệp trên mỗi thư mục. IDK về BTRFS, nhưng tôi có ấn tượng rằng nó có thể tốt cho loại điều đó.
Peter Cordes

Không phải trích dẫn thứ hai đó phụ thuộc vào loại hệ thống tập tin ...
Menasheh

@Menasheh Điểm tốt, tôi đã chỉnh sửa nó thành câu trả lời của tôi.
Hitechcomputergeek

3

Một điều bạn có thể làm là bắt đầu rmquá trình ở chế độ nền (không có đầu ra, vì vậy nó sẽ không bị chậm lại) và sau đó, theo dõi nó ở phía trước bằng lệnh (a) đơn giản :

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> _

Các find/wckết hợp có thể được thay thế bằng bất kỳ công cụ có khả năng cung cấp cho bạn các đơn vị bạn muốn.


(a) Chà, tương đối đơn giản, so với, nói, vật lý hạt nhân, giả thuyết Riemann, hoặc mua gì cho vợ tôi cho Xmas :-)


0

Cách đây một thời gian tôi đã viết một cái gì đó để in tốc độ mà các dòng được in. Bạn có thể chạy rm -rfv | ./countervà nó sẽ in các dòng mỗi giây / phút. Mặc dù không phải là một tiến trình trực tiếp, nhưng nó sẽ cung cấp cho bạn một số phản hồi về tốc độ tiến trình, có thể là rmlang thang vào một hệ thống tập tin mạng hoặc có lẽ tương tự?

Liên kết đến mã ở đây:

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

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.