Come posso sapere dove si trova fisicamente un file sul disco (numeri di blocco)?

10

Questa è una domanda oscura, lo so. Sto provando a fare alcuni test delle prestazioni di alcuni dischi su un box Linux. Sto ottenendo risultati incoerenti, eseguendo lo stesso test sullo stesso disco. So che i dischi hanno prestazioni diverse a seconda della parte del disco a cui si accede. In particolare, le letture e le scritture all'esterno del disco hanno un throughput molto più elevato rispetto alle letture e alle scritture nella parte interna del disco, a causa della densità dei dati quasi costante e della velocità di rotazione costante.

Mi piacerebbe vedere se le mie incongruenze possono essere attribuite a questa varianza indotta dalla geometria nel rendimento. È possibile, utilizzando gli strumenti esistenti, scoprire dove è stato posizionato un file sul disco?

Altrimenti, suppongo di poter scrivere qualcosa per cercare, leggere e scrivere direttamente sul file del dispositivo stesso, bypassando (e distruggendo) il filesystem, ma spero di evitarlo. Attualmente sto usando ext4 su un kernel 3.0 (Arch Linux, se è importante), ma sono interessato anche alle tecniche per altri filesystem.

— Rick Koshi
fonte

1

chi dice che i file si trovano in un unico posto? Se vengono frammentati (cosa che fanno di solito) possono finire dappertutto.

— Sirex,

Assolutamente. Ma sono ancora da qualche parte :-) E nel mio caso particolare, scrivendo file su un filesystem appena creato, è molto probabile che siano (per lo più) non frammentati.

— Rick Koshi,

Non puoi farlo. Il meglio che puoi ottenere sono i numeri di blocco LBA dei file, che non corrispondono necessariamente a posizioni fisiche specifiche (almeno non in un modo che puoi determinare, poiché le unità non pubblicano questa mappatura). Ci sono anche altre cose, ad esempio, i blocchi 3-5 possono essere numerati consecutivamente, ma 4 potrebbero essere stati riallocati in una posizione completamente diversa sull'unità perché il settore originale in 4 era fisicamente danneggiato, ecc. Non è possibile ottenere le informazioni stai cercando a meno che il produttore del drive non sia disposto a darti specifiche di indirizzo dettagliate.

— Jason C,

7

Puoi usare debugfsper questo:

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

Modificare l'unità disco rigido / partizione di conseguenza e assicurarsi che l'unità sia smontata. Otterrai un elenco con tutti i blocchi utilizzati:

BLOCKS:
(0):1643532
TOTAL: 1

— Bart De Vos
fonte

1

Questo è perfetto, grazie. Non sono sicuro del motivo per cui hai detto di assicurarti che l'unità sia smontata. Secondo la pagina di manuale, debugfs si apre in modalità di sola lettura per impostazione predefinita, quindi questo comando dovrebbe essere completamente sicuro anche su un filesystem attivo. Potrebbe fornire risultati discutibili se il file interrogato viene modificato attivamente in quel momento, ovviamente, ma non dovrebbero verificarsi altri problemi. Ho perso qualcosa?

— Rick Koshi,

No, hai ragione. È più una "best practice" che un must. Se lo stai facendo su un filesystem attivo, i file potrebbero cambiare, ecc.

— Bart De Vos,

1

Il numero di blocco LBA non indica dove si trova fisicamente il file sul disco. In questi giorni la conversione da LBA a posizione fisica non è generalmente possibile, a causa della complessità della geometria fisica di unità moderne, riallocazioni di settori dietro le quinte, ecc. In generale, è generalmente una scommessa sicura che per i media basati su disco LBA inferiori sono rivolti verso l'esterno dell'unità, ma questo è dovuto al fatto che quel layout era tipico in passato, ai giorni degli indirizzi CHS. Le unità moderne non pubblicano più nemmeno la vera geometria CHS, perché non possono.

— Jason C,

per quanto riguarda i sistemi fat fat?

— dashesy

10

Puoi usare lo ioctl FIBMAP , come esemplificato qui , o usando 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
fonte

Sfortunatamente, nulla di output di stat è l'informazione di cui ho bisogno. Dimensione in byte e blocchi, numero di inode, permessi ... Nessuno di questi riflette quali blocchi contengono i dati del file. Ad esempio, i miei file di test (che hanno tutte le stesse dimensioni) mostrano tutti esattamente gli stessi dati, ad eccezione del numero di inode e dei tempi di accesso / modifica.

— Rick Koshi,

Sì, hai ragione, mi dispiace, non ho letto bene. Ho cambiato la mia risposta per stg più appropriato.

— Francois G,

hdparm mi dà davvero ciò di cui ho bisogno e in un formato un po 'più leggibile rispetto a debugfs. Ho dovuto andare a trovarlo, però, poiché non è installato (su Arch Linux) per impostazione predefinita. debugfs fa parte di e2fsprogs (stesso pacchetto che ci fornisce mkfs e fsck), quindi è installato di default.

— Rick Koshi,

L'LBA non ti dice dove si trova fisicamente il file sull'unità. Non è possibile ottenere informazioni sull'effettiva mappatura fisica degli LBA.

— Jason C,

Capisco tutto questo:HDIO_GETGEO failed: Inappropriate ioctl for device

— puntuale, il

5

Questo thread può darti un'idea dell'algoritmo di posizionamento dei file ext4.

debugfsha una bmapfunzione, che sembra fornire i dati desiderati. Dovresti essere in grado di assegnargli blocchi consecutivi di un file e ottenere i numeri di blocco fisici.

— Paweł Brodacki
fonte

1

Grazie per il puntatore al thread sul posizionamento dei file ext4. È stato illuminante. :-)

— Rick Koshi,

L'LBA non ti dice dove si trova fisicamente il file sull'unità. Non è possibile ottenere informazioni sull'effettiva mappatura fisica degli LBA.

— Jason C,

2

La domanda è piuttosto vecchia, ma c'è un'altra risposta che potrebbe essere utile per coloro che la trovano su Google: filefrag(in Debian è all'interno del pacchetto 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

Ha il vantaggio che funziona anche con altri filesystem (l'ho usato per UDF), che non sembrano essere supportati da altri strumenti qui descritti.

L'offset presentato nell'output dovrebbe essere multiplo della dimensione del blocco scritta nella seconda riga (4096 qui). Attenzione che gli offset logici potrebbero non essere contigui, in quanto un file può presentare buchi (quando supportato dal filesystem).

— Giovanni Mascellani
fonte