¿Cómo puedo comprobar la ubicación de un archivo (por ejemplo, el clúster o el número de sector) en el almacenamiento interno?

Supongo que al decir grupo te refieres a Windows'. unidad de asignación , comúnmente llamado bloque en el mundo de Linux. Es una unidad de almacenamiento de datos que utiliza un sistema de archivos. Un cluster/bloque puede consistir o corresponder a múltiples sectores en el medio de almacenamiento subyacente (disco duro o almacenamiento flash). El sector es la unidad atómica mínima de almacenamiento que un sistema operativo puede leer o escribir. El tamaño del bloque se decide en el momento de la creación del sistema de archivos, es decir, cuando formateamos una partición ( high-level formatting ). Las particiones y los sistemas de archivos facilitan la clasificación y organización de nuestros datos en el dispositivo de almacenamiento físico.

UNIDADES DE DISCO DURO

"Sector" puede referirse a un sector físico o sector lógico . En los primeros tiempos de los discos duros sólo existían sectores físicos creados al dividir en pequeñas partes los grupos/pistas de los discos giratorios. C ylinder/ H ead/ S ector (CHS) ha sido un método popular de abordar antes del L ogical B bloquear A dimiento (LBA) fue ideado. En lugar de tratar directamente con los sectores físicos, el SO ahora habla con el firmware de la controladora de disco (a través de comandos SATA/SCSI) refiriéndose a un número LBA. El firmware, a su vez, mantiene un Asignación de LBA a CHS mismo, que incluye ECC , Lista G (tabla de defectos del disco), etc. Este mapeo (1:1 / secuenciado / lineal) ( ref ) se crea durante low-level formatting de la unidad de disco en el momento de la fabricación, que nunca cambia, excepto si algún sector se marca como malo y se reasigna a algún sector de repuesto. Así que el sistema operativo / sistema de archivos es consciente de la geometría física del disco, que es propocional a la geometría de LBAs.

ALMACENAMIENTO FLASH

En los soportes flash (SSD, eMMC, UFS, tarjetas SD, etc.) no hay discos giratorios y, por tanto, no hay cilindros. La memoria flash NAND está formada por celdas de silicio, cada una de las cuales consta de un ( S ingle- L evel- C ell), dos ( M ulti- LC ), tres ( T riple- LC ) o cuatro ( Q uad- LC ) bits. Las celdas se agrupan en páginas (por ejemplo, de 4KB) y páginas en borrar bloques (por ejemplo, de 128 KB). LBAs a P hysical B bloquear A La asignación de direcciones está totalmente controlada por F pestaña T ón L ayer; una parte del firmware del controlador flash. El sistema operativo no sabe nada al respecto, puede ver como máximo los LBAs, no lo que ocurre por debajo. Ni siquiera el ECC de las celdas de memoria que fallan, y por eso no nos damos cuenta de la mala salud de la eMMC a menos que falle, excepto al leer EXT_CSD (requiere Root) usando mmc-utils o de /sys/class/mmc_host/*/*/life_time (si el controlador lo admite).

Dado que una página de memoria no puede sobrescribirse sin más, a diferencia de los discos duros, toda una EraseBlock tiene que ser Borrado primero antes de ser Programado (escrito). Un efecto secundario es que se borran/reescriben varias páginas y el mapeo físico cambia incluso si se edita un archivo pequeño. Esta innecesaria lectura-modificación-escritura ( RMW ) se llama W rite A mplificación. En los discos duros, los archivos no se sustituyen físicamente a menos que se acorten o alarguen. El sistema operativo es consciente de estos cambios físicos en el disco duro, pero no en la memoria flash.

¿QUÉ ES EL SECTOR?

Al fin y al cabo lo que nos preocupa es el sector lógico. Los medios de almacenamiento informan al sistema operativo del tamaño de su sector lógico, pero "la por defecto de 512 cubre la mayor parte del hardware" porque los discos duros han estado utilizando 512B desde los primeros tiempos, aunque las cosas han cambiado con Formato 4Kn también para los discos duros. 512B es el tamaño que ve el SO, en realidad es un poco más grande para dejar espacio a la cabecera, ECC, etc. El tamaño del sector físico en el almacenamiento flash es de ninguna utilidad a nosotros.

Sus preguntas:

Me gustaría saber si un determinado archivo se mueve en la memoria Flash (almacenamiento interno), entre las escrituras/actualizaciones del mismo.

Depende de la definición de "mover" . En el almacenamiento flash, aunque no se escriba en un archivo, éste puede seguir cambiando su verdadera ubicación física debido al fondo G arbage C ollección; un fenómeno controlado por FTL internamente para reducir la WA, para lograr Nivelación del desgaste y para proporcionar un alto rendimiento de escritura ( Programa operaciones) borrando páginas no válidas en el fondo ( Borrar operaciones).

¿Hay alguna forma de obtener la ubicación del archivo en la memoria Flash (número de clúster, número de sector, etc.)?

Sí, puede obtener las direcciones de bloque del sistema de archivos de un archivo que tienen un mapeo lineal con los LBA del dispositivo de bloque subyacente (partición). Pero estas direcciones no son las reales/físicas ubicación del archivo en la memoria Flash . Sin embargo, normalmente uno no se preocupa por la verdadera ubicación física, a menos que se trate de algún tipo de análisis forense o de recuperación de datos.

EJEMPLO

~# cat /sys/block/mmcblk0/queue/logical_block_size
512
~# blockdev --getss /dev/block/by-name/cache
512
~# tune2fs -l /dev/block/by-name/cache | grep 'Block size'
Block size:               4096

Así que el tamaño del sector aquí es de 512B mientras que el tamaño del bloque del sistema de archivos es de 4KiB. Vamos a crear un archivo de prueba:

~# echo foobar >/cache/test_file
~# cat /cache/test_file
foobar
~# filefrag -sv -b512 /cache/test_file
Filesystem type is: ef53
File size of /cache/test_file is 7 (8 block of 512 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:   
   0:        0..       7:     307200..    307207:      8:             last,eof
/cache/test_file: 1 extent found

* debugfs -R 'stat test_file' /dev/block/by-name/cache también puede utilizarse en lugar de filefrag

El archivo creado (de 7 bytes de tamaño) ocupa 1 bloque del sistema de archivos. -b 512 convierte el tamaño del bloque (4096B) en el tamaño del sector (512B). "archivo_de_prueba" debe estar a 307200 th sector, lo mismo para la partición y el sistema de archivos porque el sistema de archivos ocupa toda la partición:

~# blockdev --getsize64 /dev/block/by-name/cache | awk '$1 /= 4096'
65536
~# tune2fs -l /dev/block/by-name/cache | grep 'Block count'
Block count:              65536

Vamos a leer el archivo directamente desde la partición:

~# dd if=/dev/block/by-name/cache skip=307200 count=1 | head -c7
foobar

Está ahí. Ahora localiza el archivo desde el inicio de la eMMC:

~# readlink /dev/block/by-name/cache
/dev/block/mmcblk0p25
~# cat /sys/block/mmcblk0/mmcblk0p25/start
7471104
~# dd if=/dev/block/mmcblk0 skip=$(( 7471104 + 307200 )) count=1 | head -c7
foobar

Así, aunque se borren el sistema de archivos y la partición, se puede leer el archivo (siempre que no se sobrescriba).

Vamos a investigar un poco más:

~# rm /cache/test_file; sync; echo -n 1 >/proc/sys/vm/drop_caches
~# dd if=/dev/block/mmcblk0 skip=$(( 7471104 + 307200 )) count=1 | head -c7
foobar

El archivo se borra del sistema de archivos, pero físicamente sigue ahí. Pidamos a FTL que lo borre definitivamente:

~# fstrim /cache; sync; echo -n 1 >/proc/sys/vm/drop_caches
~# dd if=/dev/block/mmcblk0 skip=$(( 7471104 + 307200 )) count=1 | head -c7

Y se ha ido. Pero lo más probable es que siga ahí en algún lugar de O ver- P rovisión del espacio , programado para ser Borrado en la próxima GC, sólo que no sabemos dónde está.

Nota:

• dd en las particiones desnudas es un asesino. Tengan cuidado.
• tune2fs y filefrag forman parte de e2fsprogs . filefrag no viene con Android, construye desde el código fuente o intenta este . fstrim es un applet de busybox.

RELACIONADO:

• ¿Cuándo debe funcionar fstrim?
• ¿Qué hace que la recuperación de datos borrados sea difícil / imposible?