เหตุใด rm จึงช้าในไดรฟ์จัดเก็บข้อมูลภายนอก (เชื่อมต่อ USB, ประเภทฟิวส์) ด้วยไฟล์ 50Gb?

21

ฉันพยายามใช้rsnapshotเพื่อทำการสำรองข้อมูล แต่ฉันพบว่ามันใช้ไม่ได้ ในขณะที่สามารถกระจายไดเรกตอรี (50gb) และทำซ้ำ (ฮาร์ดลิงก์ทุกไฟล์) ในเวลาไม่กี่นาทีและฉันสามารถ cp ไดเรกตอรีทั้งหมดในเวลาประมาณครึ่งชั่วโมง แม้จะใช้โดยตรงrm -rfvฉันพบว่าอาจใช้เวลานานถึงครึ่งวินาทีในการแปลงไฟล์เดียวในขณะที่คำสั่งcpและlinkคำสั่งเสร็จสมบูรณ์ทันที

ทำไม RM ถึงช้าจัง? มีวิธีใดที่เร็วกว่าในการลบการทำลิงก์ซ้ำซ้ำหรือไม่ สำหรับฉันแล้วการคัดลอกไฟล์ควรใช้เวลาน้อยกว่าการลบออก

ระบบไฟล์ที่ฉันกำลังทำงานอยู่นั้นเป็นไดรฟ์จัดเก็บข้อมูลภายนอกเชื่อมต่อผ่าน usb และพิมพ์ฟิวส์ (ซึ่งฉันคิดว่ามันคือ ntfs) คอมพิวเตอร์ของฉันใช้งาน Ubuntu Linux

ผลผลิตจากด้านบน:

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
แหล่งที่มา

1

การติดตั้งfuseblkไม่ได้หมายความว่าไดรฟ์นั้นเป็น NTFS แต่ก็หมายความว่ามันถูกติดตั้งเป็นอุปกรณ์บล็อก FUSE นั่นอาจเป็นอะไรก็ได้

— Chris Down

1

@ChrisDown จริง แต่ฉันรู้ว่ามันเป็น NTFS หรือ ext3 และฉันค่อนข้างแน่ใจว่ามันเป็น ext3 มันจะถูกเมานท์เช่นนี้โดยการเมาท์โดยไม่มีข้อโต้แย้ง

— Benubird

1

ขึ้นอยู่กับจำนวนไฟล์ในไดเรกทอรี (คุณไม่ได้บอกว่ามีจำนวนเท่าใด) และโดยเฉพาะอย่างยิ่ง NTFS จะช้าลงด้วยไฟล์> 3K เท่านั้นในไดเรกทอรี ค่อนข้างทุกระบบไฟล์อื่น ๆ ที่มีประสิทธิภาพมากขึ้น ดูโพสต์อื่น ๆ อีกมากมายใน SO / SE เกี่ยวกับผลกระทบของจำนวนไฟล์ที่มีต่อประสิทธิภาพของระบบไฟล์

— smci

28

ท้ายที่สุดไม่ว่าคุณจะทำอะไรrmต้องทำงานunlinkกับไฟล์ทุกไฟล์ที่คุณต้องการลบ (แม้ว่าคุณจะเรียกrm -rใช้ไดเรกทอรีหลัก) หากมีไฟล์จำนวนมากที่จะลบมันอาจใช้เวลานาน

มีสองกระบวนการที่ใช้เวลานานโดยเฉพาะเมื่อคุณเรียกใช้rm -r:

readdir, ติดตามโดย,
unlinkจำนวนของการโทรไปยัง

การค้นหาไฟล์ทั้งหมดแล้วผ่านทุกไฟล์เดียวเพื่อลบมันอาจใช้เวลานานมาก ๆ

หากคุณพบว่า "ไม่สามารถใช้งานได้" เพราะมันทำให้ไดเรกทอรีใช้งานไม่ได้ในบางครั้งให้ลองย้ายไดเรกทอรีหลักก่อนที่จะลบออก นี่จะทำให้ชื่อนั้นว่างสำหรับโปรแกรมที่จะใช้อีกครั้งโดยไม่ต้องใช้เวลามากเกินไปในความไม่สะดวก

สมมติว่าระบบไฟล์เป็น NTFS จริงๆ(มันไม่ชัดเจนจากคำถามของคุณ) โดยทั่วไปแล้ว NTFS ค่อนข้างช้าในการลบไฟล์ขนาดใหญ่ คุณอาจพิจารณาใช้ระบบไฟล์ที่เหมาะสมกว่าสำหรับวัตถุประสงค์ของคุณ (ระบบไฟล์ ext ล่าสุดมีประสิทธิภาพในการลบที่ค่อนข้างดีถ้าคุณไม่มีความต้องการพิเศษอื่น ๆ ) โดยทั่วไปแล้ว FUSE นั้นยังไม่เร็วนัก คุณอาจลองพิจารณาดูว่าคุณสามารถทำได้ในวิธีที่ไม่ใช้ FUSE หรือไม่

— คริสลง
แหล่งที่มา

2

+1 จริง ๆ แล้วขึ้นอยู่กับระบบไฟล์ที่แน่นอน - หลายคนมักจะทำงานได้ดีสำหรับการดำเนินการบางอย่างในขณะที่กำลังซบเซากับคนอื่น ๆ

— เตอร์

15

ทำไม RM ถึงช้าจัง? ฉันไม่รู้. แต่ฉันรู้วิธีที่เร็วกว่า:

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

ปรับปรุง: คำตอบนี้ใน Serverfault มีคำอธิบายบางอย่าง ดูเหมือนว่า rsync จะลบไฟล์ตามลำดับเฉพาะที่ทำให้โครงสร้างระบบไฟล์มีความสมดุลและไม่จำเป็นต้องทำการปรับสมดุล rm จะลบไฟล์ออกไปและทำให้เกิดการปรับสมดุลใหม่ ๆ มีข้อมูลบางอย่างเกี่ยวกับการปรับสมดุลคือที่นี่

— rjmunro
แหล่งที่มา

1

คุณเคยเปรียบเทียบกับสิ่งนี้แล้วrm -rfหรือยัง? rsyncยังคงมีunlink()ไฟล์ทั้งหมดในtest/และนั่นอาจเป็นสิ่งที่ต้องใช้เวลา

— MattBianco

ฉันไม่ได้ทำการเปรียบเทียบอย่างเป็นทางการ แต่ฉันได้ลองทำหลังจากอ่านการวัดประสิทธิภาพของคนอื่นและความแตกต่างนั้นมีความสำคัญมาก ฉันไม่พบโพสต์นั้นอีกต่อไป แต่คำตอบนี้ใน serverfault มีคำอธิบายและแหล่งข้อมูลสำหรับโปรแกรมลบที่เร็วยิ่งขึ้น

— rjmunro

แต่วิธีที่เร็วที่สุดจะต้องunlink(2)อยู่ในไดเรกทอรี (และจำได้ว่าจะทำในfsckภายหลัง) ...

— MattBianco

ความจริงคือความจริง เพิ่งหมดเวลาและเร็วเกือบสองเท่า หลังจากอ่าน GNU coreutils rm code มันไม่ได้ทำให้ฉันประหลาดใจ ...

— Dominik George

1

ฉันเคยมีปัญหาคล้ายกันกับคุณ ฉันพบว่า "วา" ของคุณสูงคุณสามารถใช้

iostat -x 1

เพื่อตรวจสอบว่าการใช้ดิสก์ของคุณสูงหรือไม่ถ้าใช่หมายความว่าดิสก์ของคุณไม่ว่าง ตรวจสอบว่ากระบวนการอื่นกำลังเขียนลงดิสก์อย่างต่อเนื่องหรือไม่

สำหรับความง่ายใช้

vmstat 1

เพื่อตรวจสอบว่าขสูงหรือR < ข แสดงว่ามีบางอย่างผิดปกติ ในสถานการณ์ของคุณฉันคิดว่าดิสก์ io นั้นเป็นเหตุผลดั้งเดิม

— fibonacci
แหล่งที่มา