Làm thế nào tôi có thể tìm ra vị trí của một tập tin trên đĩa (số khối)?

10

Đây là một câu hỏi mơ hồ, tôi biết. Tôi đang cố gắng thực hiện một số thử nghiệm hiệu năng của một số đĩa trên hộp Linux. Tôi nhận được một số kết quả không nhất quán, chạy cùng một bài kiểm tra trên cùng một đĩa. Tôi biết rằng các đĩa có hiệu suất khác nhau tùy thuộc vào phần nào của đĩa đang được truy cập. Cụ thể, đọc và ghi vào bên ngoài đĩa có thông lượng cao hơn nhiều so với đọc và ghi vào phần bên trong của đĩa, do mật độ dữ liệu gần như không đổi và tốc độ quay không đổi.

Tôi muốn xem liệu sự không nhất quán của tôi có thể được quy cho phương sai hình học gây ra trong thông lượng này hay không. Có thể, bằng cách sử dụng các công cụ hiện có, để tìm ra vị trí của một tập tin trên đĩa?

Nếu không, tôi cho rằng tôi có thể viết một cái gì đó để trực tiếp tìm kiếm, đọc và ghi vào tệp thiết bị, bỏ qua (và phá hủy) hệ thống tệp, nhưng tôi hy vọng sẽ tránh được điều đó. Tôi hiện đang sử dụng ext4 trên kernel 3.0 (Arch Linux, nếu có vấn đề), nhưng tôi cũng quan tâm đến các kỹ thuật cho các hệ thống tệp khác.

— Rick Koshi
nguồn

1

Ai nói tập tin ở một nơi? Nếu họ bị phân mảnh (điều họ thường làm), họ có thể kết thúc tất cả.

— Sirex

Chắc chắn rồi. Nhưng chúng vẫn còn ở đâu đó :-) Và trong trường hợp cụ thể của tôi, viết các tệp vào một hệ thống tệp mới được tạo, chúng hoàn toàn có khả năng (hầu hết) không bị phân mảnh.

— Rick Koshi

Bạn không thể làm điều này. Điều tốt nhất bạn có thể nhận được là số khối LBA của các tệp, không nhất thiết phải tương ứng với các vị trí thực tế được chỉ định (ít nhất là không theo cách bạn có thể xác định, vì các ổ đĩa không xuất bản ánh xạ này). Cũng có những thứ khác, ví dụ, các khối 3-5 có thể được đánh số liên tiếp, nhưng 4 có thể đã được phân bổ lại đến một vị trí hoàn toàn khác trên ổ đĩa vì khu vực ban đầu ở số 4 bị hư hỏng về mặt vật lý, v.v. Bạn không thể lấy thông tin bạn đang tìm kiếm trừ khi nhà sản xuất ổ đĩa sẵn sàng cung cấp cho bạn thông số kỹ thuật địa chỉ chi tiết.

— Jason C

7

Bạn có thể sử dụng debugfscho việc này:

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

Thay đổi ổ đĩa cứng / phân vùng phù hợp và đảm bảo ổ đĩa không bị ngắt. Bạn sẽ nhận được một danh sách với tất cả các khối được sử dụng:

BLOCKS:
(0):1643532
TOTAL: 1

— Bart De Vos
nguồn

1

Điều này là hoàn hảo, cảm ơn. Tôi không chắc chắn lý do tại sao bạn nói để chắc chắn rằng ổ đĩa không được đếm. Theo trang hướng dẫn, debugfs mở ở chế độ chỉ đọc theo mặc định, vì vậy lệnh này phải hoàn toàn an toàn ngay cả trên một hệ thống tệp đang hoạt động. Tất nhiên, nó có thể cung cấp kết quả đáng ngờ nếu tệp được yêu cầu đang được thay đổi tích cực, nhưng không có vấn đề nào khác xảy ra. Tôi đã bỏ lỡ một cái gì đó?

— Rick Koshi

Không, bạn đúng. Đó là nhiều hơn một "thực hành tốt nhất" thì phải. Nếu bạn đang làm điều đó trên một hệ thống tệp đang hoạt động, các tệp có thể thay đổi, v.v.

— Bart De Vos

1

Số khối LBA không cho bạn biết tệp nằm ở đâu trên đĩa. Ngày nay, việc chuyển đổi từ LBA sang vị trí thực tế thường không thể thực hiện được, do sự phức tạp của hình học vật lý của các ổ đĩa hiện đại, phân bổ khu vực hậu trường, v.v. Nói chung, đó thường là đặt cược an toàn cho các phương tiện truyền thông dựa trên đĩa thấp hơn đang hướng ra bên ngoài ổ đĩa, nhưng đó chỉ là do cách bố trí đó là điển hình trong quá khứ, trở lại trong những ngày giải quyết CHS. Các ổ đĩa hiện đại thậm chí không xuất bản hình học CHS thực sự nữa, bởi vì chúng không thể.

— Jason C

Hệ thống fie béo thì sao?

— bảnh bao

10

Bạn có thể sử dụng ioctl FIBMAP , như được minh họa ở đây hoặc sử dụng 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
nguồn

Thật không may, không có gì đầu ra bởi stat là thông tin tôi cần. Kích thước tính bằng byte và khối, số inode, quyền ... Không ai trong số những phản ánh mà khối chứa dữ liệu của tập tin. Ví dụ, các tệp thử nghiệm của tôi (tất cả đều có cùng kích thước) đều hiển thị chính xác cùng một dữ liệu, ngoại trừ số inode và thời gian truy cập / sửa đổi.

— Rick Koshi

Vâng, bạn nói đúng, tôi xin lỗi, tôi đã không đọc đúng. Tôi thay đổi câu trả lời của tôi để stg thích hợp hơn.

— Francois G

hdparm thực sự cung cấp cho tôi những gì tôi cần, và ở một định dạng dễ đọc hơn so với gỡ lỗi. Tôi đã phải đi tìm nó, mặc dù, vì nó không được cài đặt (trên Arch Linux) theo mặc định. debugfs là một phần của e2fspross (cùng gói cung cấp cho chúng tôi mkfs và fsck), do đó được cài đặt theo mặc định.

— Rick Koshi

LBA không cho bạn biết tập tin nằm ở đâu trên ổ đĩa. Không thể có được thông tin về ánh xạ vật lý thực tế của LBA.

— Jason C

Tôi nhận được điều này trên chất béo:HDIO_GETGEO failed: Inappropriate ioctl for device

— bảnh bao

5

Chủ đề này có thể cung cấp cho bạn một số cái nhìn sâu sắc về thuật toán vị trí tệp ext4.

debugfscó một bmapchức năng, dường như cung cấp dữ liệu bạn muốn. Bạn sẽ có thể cung cấp cho nó các khối liên tiếp của một tệp và lấy số khối vật lý.

— Brodacki
nguồn

1

Cảm ơn con trỏ đến luồng về vị trí tệp ext4. Đó là sự giác ngộ. :-)

— Rick Koshi

LBA không cho bạn biết tập tin nằm ở đâu trên ổ đĩa. Không thể có được thông tin về ánh xạ vật lý thực tế của LBA.

— Jason C

2

Câu hỏi khá cũ, nhưng có một câu trả lời khác có thể hữu ích cho những người tìm thấy điều này trên Google: filefrag(trong Debian nó nằm trong gói 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

Nó có lợi thế là nó cũng hoạt động cho các hệ thống tập tin khác (tôi đã sử dụng nó cho UDF), dường như không được hỗ trợ bởi các công cụ khác được mô tả ở đây.

Phần bù được trình bày ở đầu ra có nghĩa là nhiều kích thước khối được ghi trong dòng thứ hai (4096 ở đây). Xin lưu ý rằng phần bù logic có thể không liền kề nhau, vì một tệp có thể có lỗ hổng trong đó (khi được hệ thống tệp hỗ trợ).

— Giovanni Mascellani
nguồn