Si je comprends bien, chaque fichier sur un système d'exploitation de type Unix a un numéro d'inode (qui peut être visualisé avec "ls -i"), et chaque inode est une liste de blocs de disque qui contiennent les données réelles d'un fichier.
Existe-t-il une commande Linux qui prend un nom de fichier comme argument et affiche la liste des blocs de disque vers lesquels pointe l'inode de ce fichier ?
P.S. Le système de fichiers en question est ext3.
Vous pouvez utiliser l'outil "debugfs" pour afficher les informations sur les fichiers en ligne de commande ou de manière interactive. l'un ou l'autre :
# debugfs /dev/<spartition>
# stat /path/to/fileou
# debugfs -R "stat /path/to/file" /dev/<partition>par exemple :
# debugfs -R "stat /etc/passwd" /dev/sda5
Inode: 435914 Type: regular Mode: 0644 Flags: 0x0
Generation: 979004472 Version: 0x00000000
User: 0 Group: 0 Size: 1577
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4a2d6f78 -- Mon Jun 8 23:07:20 2009
atime: 0x4a2d6f79 -- Mon Jun 8 23:07:21 2009
mtime: 0x4a2d6f78 -- Mon Jun 8 23:07:20 2009
Size of extra inode fields: 4
BLOCKS:
(0):1767438
TOTAL: 1
Notez que l'argument pour 'stat' n'est pas toujours /path/to/file. L'utilisation de /path/to/file fonctionne pour les fichiers sur les systèmes de fichiers racine (montés sur /) mais pas pour les chemins montés sur d'autres systèmes de fichiers. Dans ce cas, on peut obtenir le message d'erreur suivant File not found by ext2_lookup . Il est donc préférable d'utiliser la notation inode pour l'argument de stat. Utilisez ls -i pour obtenir le numéro d'inode d'un fichier, puis invoquez debugfs avec ce numéro dans '<>' au lieu de /path/to/file. Par exemple : # debugfs -R "stat <1234567>" /dev/sda2
@ElazarR Pouvez-vous expliquer ce commentaire ? Pourquoi path/to/file ne fonctionne pas dans tous les cas ? Ce qui est déroutant pour moi, c'est que via debugfs ..... /dev/fs_blockdev il n'y a dans ma compréhension qu'un seul système de fichiers en considération, et tous ces fichiers à l'intérieur de ce système peuvent être accédés soit par leur chemin, soit par leur inode, que vouliez-vous exprimer ?
@humanityANDpeace , dans le cas où un fichier est dans une partition (système de fichiers) qui est en dehors du système de fichiers racine, c'est-à-dire, monté à un point de montage sous la partition racine, l'opération ext2_lookup semble échouer à trouver le chemin donné sous le périphérique donné (partition). Cela entraîne l'erreur que j'ai mentionnée. Par exemple, si vos dossiers /home sont montés à partir de /dev/sda5 sur le système de fichiers racine (qui est sur une autre partition, par exemple, /dev/sda3), alors debugfs -R "stat /home/myuser/foo.txt" /dev/sda5 entraîne une erreur. Mais invoquer debugfs -R "stat /path/on/rootfs" /dev/sda3 travaux.
hdparm --fibmap /path/to/filenameJe ne travaillerai pas sur zfs, mais sur ext4, btrfs, (v)fat, etc.
--fibmapLorsqu'il est utilisé, ce doit être le seul drapeau donné. Il requiert un chemin de fichier en tant que paramètre, et imprimera une liste du périphérique (plages de secteurs) occupés par ce fichier sur le disque. Les numéros de secteurs sont donnés sous forme de numéros LBA absolus, référencés à partir du secteur 0 du périphérique physique ( no la partition ou le système de fichiers). Ces informations peuvent ensuite être utilisées à des fins diverses, telles que l'examen du le degré de fragmentation des fichiers les plus volumineux, ou encore déterminer les secteurs à corrompre délibérément pendant les procédures de test d'injection de procédures.
Une façon simple d'obtenir la liste des blocs (sans avoir à lire la partition comme dans la fonction debugfs réponses) est d'utiliser le FIBMAP ioctl. Je ne connais pas de commande pour le faire, mais il est très simple d'en écrire une ; une rapide recherche sur Google m'a donné un exemple d'utilisation de FIBMAP qui fait exactement ce que vous voulez. Un avantage est qu'il fonctionnera sur n'importe quel système de fichiers qui supporte l'option bmap et pas seulement ext3.
Une alternative plus récente (et plus efficace) est la FIEMAP ioctl, qui peut également renvoyer des informations détaillées sur les extents (utile pour ext4).
Il y a cependant quelques détails intéressants : j'ai un cas où FIGETBSZ renvoie 4096 tandis que fstat() renvoie à st_blksize=16384 . Je peux donc m'attendre à ce qu'il y ait toujours des groupes de quatre blocs consécutifs de 4 ko au moins ?
L'autre chose est que certains systèmes de fichiers (comme OCFS2) semblent ne pas implémenter la fonction ioctl(FIBMAP) : J'ai obtenu un bloc zéro (et aucun indicateur d'erreur) pour chaque bloc de fichier logique. J'ai d'abord pensé que cela pouvait être des blocs épars, mais cela ne semble pas être le cas.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
