¿Cómo puedo averiguar dónde se encuentra físicamente un archivo en el disco (números de bloque)?

10

Esta es una pregunta oscura, lo sé. Estoy tratando de hacer algunas pruebas de rendimiento de algunos discos en una caja de Linux. Estoy obteniendo algunos resultados inconsistentes, ejecutando la misma prueba en el mismo disco. Sé que los discos tienen un rendimiento diferente según la parte del disco a la que se accede. En particular, las lecturas y escrituras en el exterior del disco tienen un rendimiento mucho mayor que las lecturas y escrituras en la parte interna del disco, debido a la densidad de datos casi constante y la velocidad de rotación constante.

Me gustaría ver si mis inconsistencias se pueden atribuir a esta variación inducida por la geometría en el rendimiento. ¿Es posible, utilizando las herramientas existentes, averiguar en qué parte del disco se ha colocado un archivo?

Si no, supongo que puedo escribir algo para buscar, leer y escribir directamente en el archivo del dispositivo, evitando (y destruyendo) el sistema de archivos, pero espero evitar eso. Actualmente estoy usando ext4 en un kernel 3.0 (Arch Linux, si es importante), pero también estoy interesado en técnicas para otros sistemas de archivos.

linux performance filesystems debugging Rick Koshi
fuente
1
¿Quién dice que los archivos están en un solo lugar? Si se fragmentan (lo que suelen hacer) pueden terminar por todas partes.
Sirex
Absolutamente. Pero todavía están en algún lugar :-) Y en mi caso particular, al escribir archivos en un sistema de archivos recién creado, es muy probable que estén (en su mayoría) sin fragmentar.
Rick Koshi
No puedes hacer esto. Lo mejor que puede obtener es el número de bloques LBA de los archivos, que no necesariamente corresponden a ubicaciones físicas especificadas (al menos no de una manera que pueda determinar, ya que las unidades no publican esta asignación). También hay otras cosas, por ejemplo, los bloques 3-5 pueden estar numerados consecutivamente, pero 4 pueden haber sido reasignados a una ubicación completamente diferente en el disco porque el sector original en 4 estaba dañado físicamente, etc. No puede obtener la información que está buscando a menos que el fabricante de la unidad esté dispuesto a darle especificaciones detalladas de la dirección.
Jason C

Respuestas:

7

Podrías usar debugfspara esto:

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

Cambie la unidad de disco duro / partición en consecuencia y asegúrese de que la unidad esté desmontada. Obtendrá una lista con todos los bloques utilizados:

BLOCKS:
(0):1643532
TOTAL: 1
Bart De Vos
fuente
1
Esto es perfecto, gracias. Sin embargo, no estoy seguro de por qué dijiste que la unidad esté desmontada. De acuerdo con la página del manual, debugfs se abre en modo de solo lectura de forma predeterminada, por lo que este comando debería ser completamente seguro incluso en un sistema de archivos activo. Puede proporcionar resultados cuestionables si el archivo consultado se está cambiando activamente en ese momento, por supuesto, pero no deberían surgir otros problemas. ¿Me he perdido algo?
Rick Koshi
No, tienes razon. Es más una "mejor práctica" que una obligación. Si lo está haciendo en un sistema de archivos activo, los archivos pueden cambiar, etc.
Bart De Vos
1
El número de bloque LBA no le indica dónde se encuentra físicamente el archivo en el disco. Estos conversión días desde LBA a la ubicación física en general, no es posible, debido a la complejidad de la geometría física de las unidades modernas, las reasignaciones del sector detrás de las escenas, etc. En términos generales es por lo general una apuesta segura que para los medios basados en disco inferior LBA están hacia el exterior de la unidad, pero eso es solo porque ese diseño ha sido típico en el pasado, en los días de abordar CHS. Las unidades modernas ya ni siquiera publican geometría CHS real, porque no pueden.
Jason C
¿Qué pasa con los sistemas fieles?
guión
10

Puede usar el FIBMAP ioctl , como se ejemplifica aquí , o usar 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
fuente
Desafortunadamente, nada de salida por estadística es la información que necesito. Tamaño en bytes y bloques, número de inodo, permisos ... Ninguno de estos refleja qué bloques contienen los datos del archivo. Como ejemplo, mis archivos de prueba (que son todos del mismo tamaño) muestran exactamente los mismos datos, excepto el número de inodo y los tiempos de acceso / modificación.
Rick Koshi
Sí, tienes razón, lo siento, no leí correctamente. Cambié mi respuesta a stg más apropiado.
Francois G
hdparm de hecho me da lo que necesito, y en un formato algo más legible que debugfs. Sin embargo, tuve que buscarlo, ya que no está instalado (en Arch Linux) de forma predeterminada. debugfs es parte de e2fsprogs (el mismo paquete que nos proporciona mkfs y fsck), por lo que está instalado de manera predeterminada.
Rick Koshi
El LBA no le dice dónde se encuentra físicamente el archivo en la unidad. No es posible obtener información sobre el mapeo físico real de los LBA.
Jason C
Me sale esto gordo:HDIO_GETGEO failed: Inappropriate ioctl for device
guioneso
5

Este hilo puede darle una idea del algoritmo de colocación de archivos ext4.

debugfstiene una bmapfunción, que parece dar los datos que desea. Debería poder darle bloques consecutivos de un archivo y obtener los números de bloque físico.

Paweł Brodacki
fuente
1
Gracias por el puntero al hilo sobre la ubicación del archivo ext4. Eso fue esclarecedor. :-)
Rick Koshi
El LBA no le dice dónde se encuentra físicamente el archivo en la unidad. No es posible obtener información sobre el mapeo físico real de los LBA.
Jason C
2

La pregunta es bastante antigua, pero hay otra respuesta que podría ser útil para quienes encuentren esto en Google: filefrag(en Debian está dentro del paquete 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

Tiene la ventaja de que funciona también para otros sistemas de archivos (lo usé para UDF), que no parecen ser compatibles con otras herramientas descritas aquí.

El desplazamiento presentado en la salida debe estar en múltiplos del tamaño de bloque escrito en la segunda línea (4096 aquí). Tenga en cuenta que las compensaciones lógicas pueden no ser contiguas, ya que un archivo puede tener agujeros (cuando el sistema de archivos lo admite).

Giovanni Mascellani
fuente