Determinazione dei numeri di estensione LVM per il file specificato

Sono attualmente impegnato in un esercizio di compiti non legati al lavoro. Ho un filesystem ext4 seduto su un volume logico. Sto testando diverse strategie di ottimizzazione delle prestazioni e questa idea mi è venuta in mente. Dal momento che pvmove può spostare singoli individui e intervalli di estensioni, esiste un modo per mappare quali estensioni fisiche contengono un determinato file (in teoria può essere il backup di file per un database o una grande condivisione di file comunemente accessibile) e spostarli in un particolare dispositivo di archiviazione (ad esempio ho un normale disco fisso e un'unità SSD nello stesso gruppo di volumi LVM)?

Ho pensato di usare "filefrag" ma poi mi sono reso conto che non ero al 100% sul fatto che i numeri di estensione sarebbero stati necessariamente usati in ordine sequenziale (quindi sapere quanti settori in ext4 vede un file non necessariamente lascerà io capisco su quale misura numeri / volumi il file è fisicamente seduto.

Qualche idea?

I due ingredienti principali sono hdparm --fibmap file, che ti dice dove si trova fisicamente il file all'interno del LV e lvs -o +seg_pe_ranges,vg_extent_sizeche ti dice dove si trova fisicamente il LV sul tuo dispositivo.

Il resto è matematica.

Quindi, per esempio:

# 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
     [...]

Non so perché sia ​​così frammentato, scaricato con wget. Può essere un buon esempio perché, come vedi, hai mal di testa senza script in qualche modo, almeno per i file frammentati. Prenderò solo il primo segmento 288776-298511 (9736 settori). Il conteggio è errato poiché non si tratta di settori a 512 byte, ma comunque.

Prima controlla che questi dati siano effettivamente corretti:

# 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: è identico, quindi stiamo leggendo LV-src nel posto giusto. Ora dove si trova la fonte LV?

# 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
[...]

Questo è noioso, questo LV non è frammentato. Nessun mal di testa qui. Comunque.

Dice che src è su / dev / dm-1 e inizia con PE 5920 e termina con PE 6047. E la dimensione PE è 32 MiB.

Vediamo quindi se possiamo leggere la stessa cosa direttamente da / dev / dm-1. Per quanto riguarda la matematica, questo è un po 'bizzarro poiché abbiamo usato blocchi di 512 byte in precedenza ...: - / ma sono pigro, quindi calcolerò il MiB e poi dividerò per 512! Ha! :-D

# 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  -

Bu Bu. Questo non è quello che stiamo cercando. Cosa è andato storto? Ah! Abbiamo dimenticato di aggiungere l'offset occupato da LVM all'inizio di un PV per la memorizzazione di metadati e schifezze LVM. Di solito questo è allineato MiB, quindi basta aggiungere un altro 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  -

Ecco qui.