แบดบล็อกใช้เวลานานเท่าใดในไดรฟ์ 1TB

29

ฉันกำลังเรียกใช้ badblocks (หรือมากกว่า "e2fsck -c") ในไดรฟ์ 1TB และหากตัวบ่งชี้ความคืบหน้าเป็นตัวบ่งชี้ใด ๆ (ไม่มีการเล่นสำนวนเจตนา) มันจะต้องใช้เวลาเกือบตลอดไป

ตอนนี้มันบอกว่า0.01% done, 30:20 elapsedจะหมายความว่าจะใช้เวลา 17 สัปดาห์หรือมากกว่านั้นเพื่อให้เสร็จสมบูรณ์ซึ่งดูเหมือนจะค่อนข้างมากในหนังสือของฉัน

นั่นเป็นเวลาปกติสำหรับการตรวจสอบที่จะใช้หรือว่าการสงสัยของฉันนั้นถูกต้องเมื่อไดรฟ์ล้มเหลวดังนั้นการตรวจสอบจึงใช้เวลาสั้นกว่านิรันดร์เพียงเล็กน้อยเท่านั้น

ฉันพบคำถามนี้ที่นี่ แต่เกี่ยวข้องกับจำนวนการส่งผ่าน

linux bad-blocks

— สตีเวนดอน
แหล่งที่มา

2

มันเกือบจะแน่นอนขึ้นอยู่กับอินเทอร์เฟซไดรฟ์และไดรฟ์ที่เลวถ้ามีจริง ๆ ล้มเหลว ฉันสามารถบอกคุณได้ในคอมพิวเตอร์เครื่องหนึ่งของฉันว่ามีการสแกน badblocks ใช้เวลาประมาณ 70 ชั่วโมงสำหรับไดรฟ์ 1.5TB ที่ต่อผ่าน SATA หากคุณที่เชื่อมต่อผ่าน USB2.0 หรือ 1.0 จะนานกว่านั้น

— Zoredache

มันถูกแนบโดยใช้ e-SATA ฉันคิดว่าฉันจะให้มันสักครู่และดูว่ามันไปไกลแค่ไหนหลังจากนอนหลับฝันดี

— Steven Don

@Zoredache - ฉันคิดว่าความคิดเห็นของคุณควรเป็นคำตอบแทน

— Nifle

นอกเหนือจากความคิดเห็นของ Zoredache ด้านบนสวิตช์ที่แตกต่างกันเพื่อbadblocksให้ทำงานต่าง ๆ ซึ่งจะมีผลต่อ runtimes ตัวอย่างเช่น-wสวิตช์

— JeffG

1

เวลาที่ต้องใช้ (เช่น) ขึ้นอยู่กับโหมดbadblocksกำลังทำงานใน: read-only, read-write แบบไม่ทำลายหรือทำลายการอ่าน - เขียนแบบทำลายล้าง ต้องบอกว่า 30 นาทีสำหรับ 0.1% ดูเหมือนจะนาน

— SabreWolfy

20

เพื่อตอบคำถามของคุณสิ่งที่ใกล้เคียงที่สุดที่ฉันสามารถให้ได้คือ 3TB ที่ฉันทดสอบสำหรับสิ่งนี้ นี่คือการทดสอบ 3 ครั้งที่ฉันทำเพียงเปลี่ยนค่าพารามิเตอร์-cและทำได้เพียง 10% เนื่องจากใช้เวลามาก แต่ละคนทำ 3 ครั้งเพื่อให้ได้ค่าเฉลี่ย

badblocks -svn /dev/sdb

ได้รับ 1%: 1 ชั่วโมง
ถึง 10%: 8 ชั่วโมง 40 นาที

badblocks -svn -b 512 -c 32768 /dev/sda

ได้รับ 1%: 35 นาที
ถึง 10%: 4 ชั่วโมง 10 นาที

badblocks -svn -b 512 -c 65536 /dev/sda

ได้รับ 1%: 16 นาที
ถึง 10%: 2 ชั่วโมง 35 นาที

ใช่-cพารามิเตอร์มีอิทธิพลอย่างมากต่อเวลาที่ใช้ในการตรวจสอบไดรฟ์ ฉันเดาว่าสำหรับฮาร์ดไดรฟ์ 1 TB สมมติว่ามันรักษากรอบเวลาเดียวกันกับ 3TB มันจะเป็น 1/3 ของเวลาที่กล่าวถึงที่นี่ดังนั้นเพื่อให้ได้ 10% โดย-c 65536ใช้ HDD 1 TB มันจะเกี่ยวกับ 50 นาที

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

5

Badblock ทำให้การทำงาน 4 ครั้ง ใน HD ภายนอก 1 TB โดยทั่วไปจะใช้เวลาประมาณ 70 ชั่วโมง

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

4

เพื่อความสมบูรณ์badblocks(เท่านั้น) มีค่าดีฟอลต์เป็นสี่การรันพร้อมกับ-wแฟล็ก destructive-write

— SabreWolfy

@ SabreWolfy คุณอ่านบล็อกแบดที่ทำงานด้วย -w ที่ไหน ฉันหาข้อมูลนี้ไม่พบ

— Alan Franzoni

1

man page สำหรับ -w แสดงสี่รูปแบบการเขียนที่ใช้

— SabreWolfy

3

badblocks -svn -b 512 -c 65536 /dev/sdaลองเพิ่มปริมาณของบล็อกการประมวลผลด้วยกันเหมือนใน ด้วยวิธีนี้ฉันสามารถตรวจสอบฮาร์ดดิสก์ 1 TB ได้ภายใน 8 ชั่วโมง

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

2

ฉันใช้งานแบดบล็อคในไดร์ฟ WD Red 4TB เนื่องจากพวกเขากำลัง 4k ไดรฟ์ภาค (ตรวจสอบโดยใช้lsblk -o NAME,PHY-SeC) -b 4096ผมทำงานกับ ผมอยากจะให้แต่ละกรณี badblocks ~ 800MB of RAM ดังนั้นผมจึงใช้ซึ่งจะช่วยให้คุณ-c 200000 4096 bytes * 200,000 blocks = 800,000 Kbพวกเขาเริ่มต้นด้วยขนาด 800 MB แต่ละอัน แต่นั่นก็คืบคลานไปตามกาลเวลา การตั้งค่าเหล่านี้มีการเร่งความเร็วที่สำคัญกว่าการตั้งค่ามาตรฐาน

มันวิ่ง1% ใน 3 นาที 56 วินาทีแต่นั่นคือ 1% ของ 4 รูปแบบ ดูเหมือนว่าจะใช้เวลามากขึ้นเมื่อคุณใกล้ถึงจุดจบของการวิ่ง มันตรวจสอบดิสก์ด้วยรูปแบบแรกในเวลาประมาณ 17 ชั่วโมงดังนั้นจึงควรทำ 4TB ให้เสร็จในเวลาประมาณ 68 ชม .

คำสั่งด้านล่างใช้การเขียนที่ทำลายความคิด

คำสั่งที่ฉันใช้คือ: badblocks -svw -b 4096 -c 200000 /dev/sdc -o bb_sdc.txt

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

0

ขับรถวันนี้เมื่อวานนี้กับไดรฟ์ 1 TB ที่ล้มเหลวใน 6TB RAID 6 ของฉัน (โหมดการเขียนแบบทำลายล้าง):

# badblocks -svw -b 4096 -c 65536 /dev/sdb

เมนบอร์ดเป็นแร็ค ASRock C2550D4I (ฉันรู้…) พร้อม 8x Samsung SpinPoint M8 HN-M101MBB (ฉันรู้ว่า…) เชื่อมต่อกับพอร์ต SATA3 ไดรฟ์คือไดรฟ์ 4K "รูปแบบขั้นสูง" ดังนั้นขนาดบล็อก 4K

badblocks ใช้เวลาประมาณ 28 ชั่วโมงจึงจะเสร็จสิ้นโดยไม่มีข้อผิดพลาด

ไดรฟ์เดี่ยวทำ ~ 105 MB / วินาที ( hdparm -tTกำหนดเวลาการอ่านบัฟเฟอร์โดยเฉลี่ย), 200–230 MB / วินาทีเมื่อทดสอบอาร์เรย์ทั้งหมด ไม่มีอะไรที่เหนือกว่าทุกวันนี้ แต่ก็ดีสำหรับไดรฟ์แล็ปท็อปรุ่นเก่า

หวังว่านี่จะช่วยได้มากเท่าที่เธรดนี้ช่วยให้ฉันค้นหาวิธีที่รวดเร็วในการทำ badblock ที่รันบนดิสก์ ฉันรู้ว่าการใช้งานมันน่าสงสัยในทุกวันนี้ แต่เมื่อก่อนหน้านี้smartctl -t longล้มเหลวเนื่องจากความล้มเหลวในการอ่านฉันตัดสินใจที่จะให้ทุกส่วนสัมผัสและเขียนใหม่สองสามครั้งเพื่อดูว่าค่า SMART จะเปลี่ยนไปอย่างไร smartctlการทดสอบอื่นกำลังอยู่ในระหว่างรอหากการทดสอบนั้นล้มเหลวฉันจะทำการซื้อไดรฟ์ใหม่

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

-1

การสังเกตประสิทธิภาพบางอย่าง:

ฉันกำลังทำงานe2fsck -c -c -v /dev/sda2ซึ่งอยู่บนอุปกรณ์นี้:

/dev/sda2  77056 976754431 976677376  3.7T Linux filesystem

รันไทม์ปัจจุบันสำหรับ 63.5% คือ 53:28:40; 53.5 ชั่วโมง อัตราความคืบหน้าคือ 1.186% / ชั่วโมง ในอัตรานี้มันจะใช้เวลาเพิ่มอีก 31 ชั่วโมงจึงจะเสร็จสมบูรณ์โดยประมาณ 85 ชั่วโมง นี่คืออุปกรณ์ USB 3.0 iotop ระบุว่าความเร็วในการอ่าน / เขียนโดยเฉลี่ยอยู่ที่ประมาณ 25MB / s จนถึงขณะนี้พบบล็อกที่ไม่ถูกต้องเป็นศูนย์

บรรทัดคำสั่งพื้นฐานที่ดำเนินการโดยe2fsckคือ:

sh -c badblocks -b 4096 -X -s -n /dev/sda2 976677375

สถานะการโพสต์ไปยัง StackOverflow ปลอดภัยที่จะขัดจังหวะการบล็อกแบดด้วย ^ C (SIGTERM) ฉันควรทำอย่างไรฉันไม่เห็นข้อเสียของการหยุดการทดสอบนี้และกลับมาทำงานต่อในอนาคตในภายหลังเนื่องจากเป็นการดำเนินการระดับดิสก์บล็อก ฉันต้องยกเลิกการต่อเชื่อมระบบไฟล์นี้ก่อนที่จะดำเนินการสแกนเปอร์เซ็นต์ต่อให้เสร็จ

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

3

นี่เป็นคำถามหรือคำตอบ?

— Pierre.Vriens