Tại sao rm chậm trên ổ lưu trữ ngoài (được kết nối USB, nhập fuseblk) với 50Gb tệp?

21

Tôi đã cố gắng sử dụng rsnapshot để tạo bản sao lưu, nhưng tôi thấy nó không sử dụng được. Mặc dù nó có thể tìm khác biệt một thư mục (50gb) và sao chép nó (liên kết cứng mọi tệp) trong vài phút và tôi có thể cp toàn bộ thư mục trong khoảng nửa giờ, nhưng phải mất hơn một giờ để xóa nó. Ngay cả khi trực tiếp sử dụng rm -rfv, tôi thấy nó có thể mất tới nửa giây để rm một tệp duy nhất, trong khi các lệnh cpvà linkhoàn thành ngay lập tức.

Tại sao rm quá chậm? Có cách nào nhanh hơn để loại bỏ đệ quy các liên kết cứng? Nó không có nghĩa với tôi rằng sao chép một tập tin sẽ mất ít thời gian hơn so với việc xóa nó.

Hệ thống tập tin tôi đang làm việc là một ổ lưu trữ ngoài, được kết nối qua usb và gõ fuseblk (mà tôi nghĩ có nghĩa là nó ntfs). Máy tính của tôi đang chạy Ubuntu linux.

Đầu ra từ đầu:

Cpu(s):  3.0%us,  1.5%sy,  0.0%ni, 54.8%id, 40.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8063700k total,  3602416k used,  4461284k free,   557604k buffers

performance rm external-hdd

— Benubird
nguồn

1

Được gắn kết fuseblkkhông có nghĩa là ổ đĩa là NTFS, nó chỉ có nghĩa là nó được gắn dưới dạng một thiết bị khối FUSE. Đó có thể là hầu hết mọi thứ.

— Chris Xuống

1

@ChrisDown Đúng, nhưng tôi biết đó là NTFS hoặc ext3 và tôi khá chắc chắn nếu đó là ext3 thì nó sẽ được gắn kết như vậy bằng cách gắn kết không có đối số.

— Benubird

1

Nó phụ thuộc vào số lượng tệp trong thư mục (bạn không nói có bao nhiêu tệp) và đặc biệt NTFS bị chậm lại chỉ với> 3K tệp trong thư mục. Khá nhiều hệ thống tập tin khác là hiệu suất cao hơn nhiều. Xem tất cả các bài đăng khác trên SO / SE về ảnh hưởng của số lượng tệp đến hiệu suất hệ thống tệp.

— smci

28

Cuối cùng, bất kể bạn làm gì, rmphải chạy unlinktrên mọi tệp mà bạn muốn xóa (ngay cả khi bạn gọi rm -rtrên thư mục mẹ). Nếu có rất nhiều tập tin để loại bỏ, điều này có thể mất nhiều thời gian.

Có hai quy trình đặc biệt tốn thời gian khi bạn chạy rm -r:

readdir, theo dõi bởi,
một số cuộc gọi đến unlink.

Tìm tất cả các tệp, và sau đó đi qua từng tệp để loại bỏ nó, có thể mất một thời gian thực sự rất dài.

Nếu bạn thấy điều này "không thể sử dụng" bởi vì nó khiến thư mục không thể sử dụng được một thời gian, hãy xem xét việc di chuyển thư mục mẹ trước khi xóa nó. Điều này sẽ giải phóng tên đó để chương trình sử dụng lại mà không có quá nhiều bất tiện.

Giả sử rằng hệ thống tệp thực sự là NTFS (không rõ ràng từ câu hỏi của bạn), NTFS thường khá chậm trong việc xóa các tệp lớn. Bạn có thể cân nhắc sử dụng một hệ thống tệp phù hợp hơn cho mục đích của mình (các hệ thống tệp mở rộng gần đây có hiệu suất xóa khá tốt, nếu bạn không có bất kỳ nhu cầu cụ thể nào khác). Nói chung, FUSE cũng không đặc biệt nhanh. Bạn có thể cân nhắc xem bạn có thể làm điều này theo cách nào đó không sử dụng FUSE không.

— Chris xuống
nguồn

2

+1 Thực sự rất nhiều phụ thuộc vào hệ thống tệp chính xác - nhiều xu hướng hoạt động thực sự tốt đối với một số thao tác trong khi chậm chạp với các hoạt động khác (thường là việc tạo tệp so với xóa so với truy cập dữ liệu).

— peterph

15

Tại sao rm quá chậm? Tôi không có ý kiến. Nhưng tôi biết một cách nhanh hơn:

mkdir blank
rsync -a --delete blank/ test/

Cập nhật: Câu trả lời này trên Serverfault có một số giải thích. Có vẻ như rsync đang xóa các tệp theo một thứ tự cụ thể làm cho cây hệ thống tệp vẫn được cân bằng và không bao giờ cần phải cân bằng lại. rm sẽ chỉ xóa các tập tin và gây ra nhiều sự cân bằng lại khi chúng bị xóa. Có một số thông tin về tái cân bằng ở đây .

— rjmunro
nguồn

1

Bạn đã điểm chuẩn này và so sánh với rm -rf? rsyncvẫn phải có unlink()tất cả các tập tin trong đó test/, và đó có lẽ là những gì cần có thời gian.

— MattBianco

Tôi đã không chính thức điểm chuẩn nó, nhưng tôi đã thử nó sau khi đọc điểm chuẩn của người khác, và sự khác biệt là đáng kể. Tôi không thể tìm thấy bài đăng đó nữa, nhưng câu trả lời này trên serverfault có một lời giải thích và nguồn cho một chương trình xóa thậm chí nhanh hơn.

— rjmunro

Nhưng phương pháp nhanh nhất phải có unlink(2)trong thư mục (và nhớ thực hiện fscksau) ...

— MattBianco

Một sự thật là một sự thật. Chỉ cần hẹn giờ, và nó nhanh gần gấp đôi. Sau khi đọc mã rm GNU coreutils, nó thậm chí không khiến tôi tự hỏi rằng

— Dominik George

1

Vâng, tôi đã từng có một vấn đề tương tự với bạn. Tôi thấy rằng "wa" của bạn cao, bạn có thể sử dụng

iostat -x 1

để kiểm tra xem đĩa của bạn có cao không, nếu vậy, điều đó có nghĩa là đĩa của bạn khá bận. Kiểm tra xem một số quá trình khác đang ghi vào đĩa liên tục.

Đối với simpility, sử dụng

vmstat 1

để kiểm tra xem b cao hay r < b . Điều đó chỉ ra một cái gì đó sai. Trong tình huống của bạn, tôi nghĩ rằng đĩa io là lý do ban đầu.

— Dailymotion
nguồn