Détermination des nombres LVM Extent pour un fichier donné

9

Je suis actuellement engagé dans un exercice de devoirs non lié au travail. J'ai un système de fichiers ext4 assis sur un volume logique. Je teste différentes stratégies de réglage des performances et cette idée m'est venue à l'esprit. Étant donné que pvmove peut déplacer des extensions individuelles et des étendues, existe-t-il un moyen de déterminer quelles extensions physiques contiennent un fichier particulier (en théorie, il peut s'agir de fichiers de sauvegarde pour une base de données ou d'un grand partage de fichiers communément utilisé) et de les déplacer vers un emplacement particulier périphérique de stockage (par exemple, j'ai un disque dur normal et un lecteur SSD dans le même groupe de volumes LVM)?

J'ai pensé à utiliser "filefrag" mais il m'est alors venu à l'esprit que je n'étais pas à 100% sur la question de savoir si les numéros d'étendue seraient nécessairement utilisés dans un ordre séquentiel (donc savoir combien de secteurs dans ext4 voit un fichier ne va pas nécessairement le laisser moi déterminer sur quelle étendue numéros / volumes le fichier est physiquement assis.

Des idées?

Bratchley
la source

Réponses:

13

Les deux principaux ingrédients sont hdparm --fibmap file, qui vous indique où le fichier est physiquement situé dans le LV, et lvs -o +seg_pe_ranges,vg_extent_sizequi vous indique où le LV est physiquement situé sur votre ou vos appareils.

Le reste, ce sont les mathématiques.

Ainsi, par exemple:

# hdparm --fibmap linux-3.8.tar.bz2 

linux-3.8.tar.bz2:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     288776     298511       9736
     4984832     298520     298623        104
     5038080     298640     298695         56
     5066752     298736     298799         64
     5099520     298824     298895         72
     [...]

Je ne sais pas pourquoi cela est si fragmenté - téléchargé avec wget. Peut être un bon exemple car, comme vous le voyez, vous avez mal à la tête sans scripter cela en quelque sorte, au moins pour les fichiers fragmentés. Je vais juste prendre le premier segment 288776-298511 (9736 secteurs). Le compte est faux car ce n'est pas des secteurs de 512 octets, mais de toute façon.

Vérifiez d'abord que ces données sont réellement correctes:

# dd if=linux-3.8.tar.bz2 bs=512 skip=0 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0506548 s, 98.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

# dd if=/dev/lvm/src bs=512 skip=288776 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.123292 s, 40.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

Wheeee.C'est identique donc nous lisons le LV-src au bon endroit. Maintenant, où est situé le LV source?

# lvs -o +seg_pe_ranges,vg_extent_size
  LV          VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert PE Ranges             Ext   

[...]
 src         lvm  -wi-ao---   4.00g                                            /dev/dm-1:5920-6047   32.00m
[...]

Maintenant c'est ennuyeux, ce LV n'est pas fragmenté. Pas de maux de tête ici. En tous cas.

Il indique que src est sur / dev / dm-1 et commence à PE 5920 et se termine à PE 6047. Et la taille de PE est de 32 Mio.

Voyons donc si nous pouvons lire la même chose directement depuis / dev / dm-1. Math-sage, c'est un peu bleargh puisque nous avons utilisé la taille de bloc de 512 octets plus tôt ...: - / mais je suis paresseux donc je vais juste calculer le MiB et ensuite diviser par 512! Ha! :-RÉ

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0884709 s, 56.3 MB/s
3858a4cd75b1cf6f52ae2d403b94a685  -

Boo-boo. Ce n'est pas ce que nous recherchons. Qu'est ce qui ne s'est pas bien passé? Ah! Nous avons oublié d'ajouter le décalage occupé par LVM au début d'un PV pour stocker les métadonnées LVM et les conneries. Habituellement, c'est aligné sur MiB, alors ajoutez simplement un autre MiB:

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776 + 1024*1024/512)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0107592 s, 463 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

Voilà.

frostschutz
la source
3
Un jour, ils construiront des statues en votre honneur.
Bratchley
Une chose cependant, une idée pourquoi mon invocation hdparm est défectueuse ?
Bratchley
En fait, je pense que je dois améliorer mon google-fu . Il s'agit d'un nouveau bogue RHEL concernant les SSD et LVM. Je suppose que cela signifie que ce fichier est déjà sur le SSD. Ha
Bratchley
Existe-t-il un autre utilitaire pour déterminer la position du fichier dans le LV jusqu'à ce qu'il corrige cela?
Bratchley
Vous l'avez déjà mentionné - filefrag. Sinon, google si un autre outil utilise fibmap ou fiemap.
frostschutz du