ฉันจะทราบได้อย่างไรว่าไฟล์อยู่ที่ใดในดิสก์ (หมายเลขบล็อก)

10

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

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

ถ้าไม่ใช่ฉันคิดว่าฉันสามารถเขียนบางสิ่งเพื่อค้นหาอ่านและเขียนไปยังไฟล์อุปกรณ์โดยตรงโดยการข้าม (และทำลาย) ระบบไฟล์ แต่ฉันหวังว่าจะหลีกเลี่ยงสิ่งนั้น ปัจจุบันฉันใช้ ext4 กับเคอร์เนล 3.0 (Arch Linux ถ้าเป็นเรื่องสำคัญ) แต่ฉันสนใจเทคนิคต่าง ๆ สำหรับระบบไฟล์อื่นเช่นกัน

— ริกโคชิ
แหล่งที่มา

1

ใครบอกว่าไฟล์อยู่ในที่เดียว หากพวกเขาแยกส่วน (ซึ่งพวกเขามักจะทำ) พวกเขาสามารถจบลง

— Sirex

อย่างแน่นอน แต่พวกเขายังคงอยู่ที่ไหนสักแห่ง :-) และในกรณีของฉันโดยเฉพาะการเขียนไฟล์ไปยังระบบไฟล์ที่สร้างขึ้นใหม่พวกเขามีแนวโน้มที่จะไม่ได้จัดระเบียบ

— Rick Koshi

คุณทำสิ่งนี้ไม่ได้ สิ่งที่ดีที่สุดที่คุณจะได้รับคือหมายเลขบล็อก LBA ของไฟล์ซึ่งไม่จำเป็นต้องตรงกับตำแหน่งทางกายภาพที่ระบุ (อย่างน้อยไม่ได้อยู่ในรูปแบบที่คุณสามารถพิจารณาได้เนื่องจากไดรฟ์ไม่เผยแพร่การทำแผนที่นี้) ตัวอย่างเช่นมีสิ่งอื่นเช่นบล็อก 3-5 อาจมีหมายเลขติดต่อกัน แต่ 4 อาจถูกจัดสรรใหม่ไปยังตำแหน่งอื่นในไดรฟ์เนื่องจากเซกเตอร์ดั้งเดิมที่ 4 เสียหายทางร่างกาย ฯลฯ คุณไม่สามารถรับข้อมูลได้ คุณกำลังมองหาเว้นแต่ผู้ผลิตไดรฟ์ยินดีที่จะให้รายละเอียดที่อยู่โดยละเอียด

— Jason C

7

คุณสามารถใช้debugfsสิ่งนี้:

debugfs -R "stat ~/myfile" /dev/hda1

เปลี่ยนฮาร์ดไดรฟ์ / พาร์ติชันให้สอดคล้องและตรวจสอบให้แน่ใจว่าไม่ได้ต่อเชื่อมไดรฟ์ คุณจะได้รับรายชื่อบล็อกทั้งหมดที่ใช้:

BLOCKS:
(0):1643532
TOTAL: 1

— Bart De Vos
แหล่งที่มา

1

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

— Rick Koshi

ไม่ถูกต้อง มันเป็น 'การปฏิบัติที่ดีที่สุด' มากกว่าจะต้องมี หากคุณกำลังทำมันบนระบบไฟล์ที่ใช้งานอยู่ไฟล์อาจมีการเปลี่ยนแปลงและอื่น ๆ

— Bart De Vos

1

หมายเลขบล็อก LBA ไม่ได้บอกคุณว่าไฟล์อยู่ที่ใดในดิสก์ ทุกวันนี้การแปลงจาก LBA เป็นตำแหน่งทางกายภาพนั้นเป็นไปไม่ได้เนื่องจากความซับซ้อนของรูปทรงทางกายภาพของไดรฟ์ที่ทันสมัยการจัดสรรภาคส่วนหลังฉาก ฯลฯ โดยทั่วไปการพูดก็มักจะเป็นวิธีที่ปลอดภัยสำหรับ LBA ที่ใช้แผ่นดิสก์ อยู่ทางด้านนอกของไดรฟ์ แต่เป็นเพราะเค้าโครงนั้นเป็นเรื่องปกติในอดีตย้อนกลับไปในวันที่ CHS กำหนด ไดรฟ์สมัยใหม่ไม่ได้เผยแพร่เรขาคณิต CHS จริงอีกต่อไปเพราะไม่สามารถทำได้

— Jason C

ระบบ fat fie มีอะไรบ้าง?

— dashesy

10

คุณสามารถใช้FIBMAP ioctlดังที่อธิบายไว้ที่นี่หรือใช้hdparm :

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8

— Francois G
แหล่งที่มา

น่าเสียดายที่ไม่มีข้อมูลใดที่ฉันต้องการ ขนาดในไบต์และบล็อกจำนวน inode สิทธิ์ ... ไม่มีของเหล่านี้สะท้อนให้เห็นถึงที่บล็อกประกอบด้วยข้อมูลของไฟล์ ตัวอย่างเช่นไฟล์ทดสอบของฉัน (ซึ่งมีขนาดเท่ากันทั้งหมด) ทั้งหมดแสดงข้อมูลเหมือนกันทุกประการยกเว้นหมายเลขไอโหนดและเวลาในการเข้าถึง / แก้ไข

— Rick Koshi

ใช่คุณพูดถูกฉันขอโทษฉันอ่านผิด ฉันเปลี่ยนคำตอบของฉันให้เหมาะสมยิ่งขึ้น

— Francois G

hdparm ให้สิ่งที่ฉันต้องการและในรูปแบบที่อ่านได้ง่ายกว่า debugfs ฉันต้องไปหามันเพราะมันไม่ได้ติดตั้ง (บน Arch Linux) โดยค่าเริ่มต้น debugfs เป็นส่วนหนึ่งของ e2fsprogs (แพ็คเกจเดียวกันที่ให้เรา mkfs และ fsck) ดังนั้นการติดตั้งโดยค่าเริ่มต้น

— Rick Koshi

LBA ไม่ได้บอกคุณว่าไฟล์อยู่ที่ไหนในไดรฟ์ ไม่สามารถรับข้อมูลเกี่ยวกับการทำแผนที่กายภาพของ LBAs ได้

— Jason C

ฉันได้รับมันไขมัน:HDIO_GETGEO failed: Inappropriate ioctl for device

— dashesy

5

เธรดนี้อาจให้ข้อมูลเชิงลึกเกี่ยวกับอัลกอริทึมการจัดตำแหน่งไฟล์ ext4

debugfsมีbmapฟังก์ชั่นซึ่งดูเหมือนจะให้ข้อมูลที่คุณต้องการ คุณควรให้บล็อกต่อเนื่องกับไฟล์และรับหมายเลขบล็อกทางกายภาพ

— Paweł Brodacki
แหล่งที่มา

1

ขอบคุณสำหรับตัวชี้ไปยังเธรดเกี่ยวกับการวางไฟล์ ext4 นั่นคือความกระจ่าง :-)

— Rick Koshi

LBA ไม่ได้บอกคุณว่าไฟล์อยู่ที่ไหนในไดรฟ์ ไม่สามารถรับข้อมูลเกี่ยวกับการทำแผนที่กายภาพของ LBAs ได้

— Jason C

2

คำถามนี้ค่อนข้างเก่า แต่มีคำตอบอีกข้อหนึ่งที่อาจเป็นประโยชน์สำหรับผู้ที่ค้นพบสิ่งนี้ใน Google: filefrag(ใน Debian มันอยู่ในแพ็คเกจe2fsprogs)

# filefrag -eX /usr/bin/aptitude
Filesystem type is: ef53
File size of /usr/bin/aptitude is 4261400 (1041 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     1fa:    15bd805..   15bd9ff:    1fb:            
   1:      1fb..     3f2:    15c6608..   15c67ff:    1f8:    15bda00:
   2:      3f3..     410:    15c8680..   15c869d:     1e:    15c6800: last,eof
/usr/bin/aptitude: 3 extents found

มันมีข้อได้เปรียบที่ใช้งานได้กับระบบไฟล์อื่น ๆ (ฉันใช้มันสำหรับ UDF) ซึ่งเครื่องมืออื่นไม่ได้รับการสนับสนุนดูเหมือนจะไม่สนับสนุน

อ็อฟเซ็ตที่แสดงในผลลัพธ์นั้นมีขนาดหลายบล็อกที่เขียนในบรรทัดที่สอง (4096 ที่นี่) ระวังว่าออฟเซ็ตแบบลอจิคัลอาจไม่ต่อเนื่องกันเนื่องจากไฟล์อาจมีช่องโหว่อยู่ (เมื่อระบบไฟล์รองรับ)

— Giovanni Mascellani
แหล่งที่มา