Як я можу дізнатися, де файл фізично розташований на диску (номери блоків)?

10

Це незначне питання, я знаю. Я намагаюся зробити тестування продуктивності деяких дисків на вікні Linux. Я отримую деякі непослідовні результати, виконуючи той самий тест на одному диску. Я знаю, що диски мають різну продуктивність залежно від того, до якої частини диска доступ. Зокрема, читання та запис на зовнішній стороні диска мають значно більшу пропускну здатність, ніж читання та запис у внутрішню частину диска, завдяки майже постійній щільності даних та постійній швидкості обертання.

Я хотів би дізнатися, чи мої невідповідності можна віднести до цієї відмінності пропускної здатності, викликаної геометрією. Чи можна, використовуючи наявні інструменти, з’ясувати, де на диску розміщений файл?

Якщо ні, то, напевно, я можу щось написати, щоб безпосередньо шукати, читати та записувати у сам файл пристрою, минаючи (і знищуючи) файлову систему, але я сподіваюся цього уникнути. Зараз я використовую ext4 на ядрі 3.0 (Arch Linux, якщо це важливо), але мене цікавлять методи і для інших файлових систем.

— Рік Коші
джерело

1

хто каже, що файли в одному місці? Якщо вони роздроблені (що зазвичай роблять), вони можуть закінчитися в усьому.

— Сірекс

Абсолютно. Але вони все ще є де- небудь :-) І в моєму конкретному випадку, записуючи файли в новостворену файлову систему, вони, швидше за все, є недефрагментованими.

— Рік Коші

Ви не можете цього зробити. Найкраще, що ви можете отримати, це номери блоків LBA файлів, які не обов'язково відповідають визначеним фізичним місцям (принаймні, не таким чином, який ви можете визначити, оскільки диски не публікують це відображення). Є й інші речі, наприклад, блоки 3-5 можуть бути пронумеровані послідовно, але 4, можливо, були перерозподілені у зовсім інше місце на диску, оскільки початковий сектор у 4 був фізично пошкоджений тощо. Ви не можете отримати інформацію якого ви шукаєте, якщо виробник дисків не бажає надати детальну специфікацію адреси.

— Jason C

7

Ви можете використовувати debugfsдля цього:

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

Змініть жорсткий / роздільний диск відповідно і переконайтесь, що він не відключений. Ви отримаєте список з усіма використаними блоками:

BLOCKS:
(0):1643532
TOTAL: 1

— Барт Де Вос
джерело

1

Це ідеально, дякую. Я не впевнений, чому ви сказали, щоб переконатися, що привід відключений, хоча. Відповідно до сторінки керівництва, налагодження відкриваються у режимі лише для читання за замовчуванням, тому ця команда повинна бути повністю безпечною навіть у активній файловій системі. Можливо, це може дати сумнівні результати, якщо файл запиту, як правило, активно змінюється в той час, але жодних інших проблем не повинно виникнути. Я щось пропустив?

— Рік Коші

Ні, ви праві. Це більше "найкраща практика", ніж обов'язкова. Якщо ви робите це в активній файловій системі, файли можуть змінюватися тощо

— Bart De Vos

1

Номер блоку LBA не вказує, де файл фізично розташований на диску. У цей час перетворення з LBA у фізичне розташування, як правило, неможливе через складність фізичної геометрії сучасних накопичувачів, перерозподіл закулісних секторів тощо. Взагалі кажучи, зазвичай це безпечна ставка, що для медіа-дисків на основі дисків нижчі LBA знаходяться до зовнішньої сторони диска, але це лише тому, що така компоновка була типовою в минулому, ще в дні CHS-адреси. Сучасні накопичувачі навіть більше не публікують справжню геометрію CHS, оскільки вони не можуть.

— Джейсон C

що з жировими системами?

— тире

10

Ви можете використовувати ioctl FIBMAP , як показано тут , або 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

— Франсуа Г
джерело

На жаль, нічого, що виводиться статистикою, - це не потрібна мені інформація. Розмір у байтах та блоках, кількість inode, дозволів ... Жоден із них не відображає, які блоки містять дані файлу. Наприклад, мої тестові файли (які однакового розміру) показують абсолютно однакові дані, за винятком номера inode та часу доступу / модифікації.

— Рік Коші

Так, ви маєте рацію, вибачте, я не прочитав належним чином. Я змінив свою відповідь на stg на більш відповідну.

— Франсуа Г

hdparm дійсно дає мені те, що мені потрібно, і в дещо більш читаному форматі, ніж налагодження. Мені довелося його знайти, оскільки він не встановлений (в Arch Linux) за замовчуванням. debugfs є частиною e2fsprogs (той самий пакет, який дає нам mkfs та fsck), тому встановлений за замовчуванням.

— Рік Коші

LBA не повідомляє вам, де файл знаходиться фізично на диску. Неможливо отримати інформацію про фактичне фізичне відображення LBA.

— Джейсон C

Я отримую це на жирі:HDIO_GETGEO failed: Inappropriate ioctl for device

— тире

5

Цей потік може дати вам деяке уявлення про алгоритм розміщення файлів ext4.

debugfsмає bmapфункцію, яка, здається, дає потрібні вам дані. Ви повинні мати можливість надавати йому послідовні блоки файлу та отримувати фізичні номери блоків.

— Paweł Brodacki
джерело

1

Дякуємо за вказівник на нитку про розміщення файлу ext4. Це було просвітливо. :-)

— Рік Коші

LBA не повідомляє вам, де файл знаходиться фізично на диску. Неможливо отримати інформацію про фактичне фізичне відображення LBA.

— Джейсон 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). Будьте уважні, що логічні зсуви можуть не бути суміжними, оскільки файл може мати в ньому дірки (якщо підтримується файловою системою).

— Джованні Масселлані
джерело