Comment savoir où se trouve physiquement un fichier sur le disque (numéros de bloc)?

10

C'est une question obscure, je sais. J'essaie de faire des tests de performances de certains disques sur une boîte Linux. J'obtiens des résultats incohérents, en exécutant le même test sur le même disque. Je sais que les disques ont des performances différentes selon la partie du disque à laquelle on accède. En particulier, les lectures et écritures à l'extérieur du disque ont un débit beaucoup plus élevé que les lectures et écritures à l'intérieur du disque, en raison d'une densité de données presque constante et d'une vitesse de rotation constante.

Je voudrais voir si mes incohérences peuvent être attribuées à cette variance de débit induite par la géométrie. Est-il possible, à l'aide des outils existants, de savoir où sur le disque un fichier a été placé?

Sinon, je suppose que je peux écrire quelque chose pour rechercher, lire et écrire directement dans le fichier de périphérique lui-même, en contournant (et en détruisant) le système de fichiers, mais j'espère éviter cela. J'utilise actuellement ext4 sur un noyau 3.0 (Arch Linux, si cela est important), mais je suis également intéressé par les techniques d'autres systèmes de fichiers.

linux performance filesystems debugging Rick Koshi
la source
1
qui dit que les fichiers sont au même endroit? S'ils sont fragmentés (ce qu'ils font habituellement), ils peuvent se retrouver partout.
Sirex
Absolument. Mais ils sont encore quelque part :-) Et dans mon cas particulier, en écrivant des fichiers dans un système de fichiers nouvellement créé, ils sont très probablement (principalement) non fragmentés.
Rick Koshi
Tu ne peux pas faire ça. Le meilleur que vous puissiez obtenir est le numéro de bloc LBA des fichiers, qui ne correspond pas nécessairement aux emplacements physiques spécifiés (du moins pas d'une manière que vous pouvez déterminer, car les lecteurs ne publient pas ce mappage). Il y a aussi d'autres choses, par exemple, les blocs 3 à 5 peuvent être numérotés consécutivement, mais 4 peuvent avoir été réaffectés à un emplacement complètement différent sur le lecteur car le secteur d'origine à 4 a été physiquement endommagé, etc. Vous ne pouvez pas obtenir les informations vous recherchez, sauf si le fabricant du lecteur est disposé à vous donner des spécifications d'adresse détaillées.
Jason C

Réponses:

7

Vous pouvez utiliser debugfspour cela:

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

Changez le disque dur / le lecteur de partition en conséquence et assurez-vous que le lecteur est démonté. Vous obtiendrez une liste avec tous les blocs utilisés:

BLOCKS:
(0):1643532
TOTAL: 1
Bart De Vos
la source
1
C'est parfait, merci. Je ne sais pas pourquoi vous avez dit de vous assurer que le lecteur n'est pas monté. Selon la page de manuel, debugfs s'ouvre en mode lecture seule par défaut, donc cette commande devrait être complètement sûre même sur un système de fichiers actif. Cela peut fournir des résultats douteux si le fichier interrogé est activement modifié à ce moment-là, mais aucun autre problème ne devrait en résulter. Ai-je raté quelque chose?
Rick Koshi
Non, tu as raison. C'est plus une «meilleure pratique» qu'un must. Si vous le faites sur un système de fichiers actif, les fichiers peuvent changer etc.
Bart De Vos
1
Le numéro de bloc LBA ne vous indique pas où se trouve physiquement le fichier sur le disque. Ces jours conversion de LBA à l' emplacement physique est généralement pas possible, en raison de la complexité de la géométrie physique des lecteurs modernes, derrière les coulisses réaffectations du secteur, etc. , il est une manière générale habituellement un fort à parier que pour abaisser les médias à base de disque LBAs sont vers l'extérieur du lecteur, mais c'est simplement parce que cette disposition a été typique dans le passé, à l'époque de l'adressage CHS. Les disques modernes ne publient même plus la vraie géométrie CHS, car ils ne le peuvent pas.
Jason C
qu'en est-il des systèmes de fat fie?
dashesy
10

Vous pouvez utiliser l' ioctl FIBMAP , comme illustré ici , ou utiliser 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
la source
Malheureusement, rien de la sortie par stat n'est l'information dont j'ai besoin. Taille en octets et blocs, nombre d'inodes, autorisations ... Aucun de ces derniers ne reflète quels blocs contiennent les données du fichier. À titre d'exemple, mes fichiers de test (qui sont tous de la même taille) affichent tous exactement les mêmes données, à l'exception du nombre d'inodes et des temps d'accès / modification.
Rick Koshi
Oui, vous avez raison, je suis désolé, je n'ai pas lu correctement. J'ai changé ma réponse pour stg plus approprié.
Francois G
hdparm me donne en effet ce dont j'ai besoin, et dans un format un peu plus lisible que debugfs. Je devais aller le trouver, car il n'est pas installé (sur Arch Linux) par défaut. debugfs fait partie de e2fsprogs (le même paquet qui nous donne mkfs et fsck), il est donc installé par défaut.
Rick Koshi
Le LBA ne vous indique pas où se trouve physiquement le fichier sur le lecteur. Il n'est pas possible d'obtenir des informations sur le mappage physique réel des LBA.
Jason C
Je reçois ceci sur la graisse:HDIO_GETGEO failed: Inappropriate ioctl for device
dashesy
5

Ce fil peut vous donner un aperçu de l'algorithme de placement de fichiers ext4.

debugfsa une bmapfonction, qui semble donner les données que vous voulez. Vous devriez pouvoir lui donner des blocs consécutifs d'un fichier et obtenir les numéros de bloc physiques.

Paweł Brodacki
la source
1
Merci pour le pointeur sur le fil de discussion sur le placement des fichiers ext4. C'était instructif. :-)
Rick Koshi
Le LBA ne vous indique pas où se trouve physiquement le fichier sur le lecteur. Il n'est pas possible d'obtenir des informations sur le mappage physique réel des LBA.
Jason C
2

La question est assez ancienne, mais il y a une autre réponse qui pourrait être utile pour ceux qui trouvent cela sur Google: filefrag(dans Debian c'est dans le paquet 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

Il a l'avantage de fonctionner également pour d'autres systèmes de fichiers (je l'ai utilisé pour UDF), qui ne semblent pas être pris en charge par d'autres outils décrits ici.

Le décalage présenté dans la sortie est censé être un multiple de la taille de bloc écrite sur la deuxième ligne (4096 ici). Attention, les décalages logiques peuvent ne pas être contigus, car un fichier peut avoir des trous (lorsqu'il est pris en charge par le système de fichiers).

Giovanni Mascellani
la source