¿Por qué hay una diferencia tan grande entre "Tamaño" y "Tamaño en disco"?

Como puede ver a continuación, hay mucha diferencia entre los campos Tamaño y Tamaño en disco en mi carpeta. ¿Porqué es eso?

Sé que el tamaño en el disco debería ser un poco más que el tamaño debido a las unidades de asignación en Windows, pero ¿por qué tanta diferencia? ¿Podría ser debido a la gran cantidad de archivos?

Por cierto, esta carpeta está en la tarjeta SD de mi teléfono Android. Dentro de esto, mi aplicación de mapas almacena sus mapas en caché y la aplicación obtiene su mapa de Google Maps.

^{Asumiré que está utilizando el sistema de archivos FAT / FAT32 aquí, ya que menciona que esta es una tarjeta SD. NTFS y exFAT se comportan de manera similar con respecto a las unidades de asignación. Otros sistemas de archivos pueden ser diferentes, pero de todos modos no son compatibles con Windows.}

Si tiene muchos archivos pequeños, esto es ciertamente posible. Considera esto:

• 50,000 archivos.

• Tamaño de clúster de 32 kB (unidades de asignación), que es el máximo para FAT32

Ok, ahora el espacio mínimo es de 50,000 * 32,000 = 1.6 GB (usando prefijos SI, no binarios, para simplificar las matemáticas). El espacio que ocupa cada archivo en el disco siempre es un múltiplo del tamaño de la unidad de asignación, y aquí asumimos que cada archivo es realmente lo suficientemente pequeño como para caber dentro de una sola unidad, con algo de espacio (desperdiciado) sobrante.

Si cada archivo promediara 2 kB, obtendrías aproximadamente 100 MB en total, pero también estás desperdiciando 15 veces eso (30 kB por archivo) en promedio debido al tamaño de la unidad de asignación.

Explicación en profundidad

¿Por qué pasó esto? Bueno, el sistema de archivos FAT32 necesita realizar un seguimiento de dónde se almacena cada archivo. Si fuera a mantener una lista de cada byte, la tabla (como una libreta de direcciones) crecería a la misma velocidad que los datos y desperdiciaría mucho espacio. Entonces, lo que hacen es usar "unidades de asignación", también conocidas como "tamaño del clúster". El volumen se divide en estas unidades de asignación y, en lo que respecta al sistema de archivos, no se pueden subdividir; esos son los bloques más pequeños que puede abordar. Al igual que tiene un número de casa, pero a su cartero no le importa cuántas habitaciones tiene o quién vive en ellas.

Entonces, ¿qué sucede si tienes un archivo muy pequeño? Bueno, al sistema de archivos no le importa si el archivo es de 0 kB, 2 kB o incluso 15 kB, le dará el menor espacio posible; en el ejemplo anterior, eso es 32 kB. Su archivo solo está usando una pequeña cantidad de este espacio, y el resto está básicamente desperdiciado, pero aún pertenece al archivo, al igual que un dormitorio que deja desocupado.

¿Por qué hay diferentes tamaños de unidades de asignación? Bueno, se convierte en una compensación entre tener una mesa más grande (libreta de direcciones, por ejemplo, decir que John posee una casa en 123 Fake Street, 124 Fake Street, 666 Satan Lane, etc.), o más espacio desperdiciado en cada unidad (casa). Si tiene archivos más grandes, tiene más sentido usar unidades de asignación más grandes, porque un archivo no obtiene una nueva unidad (casa) hasta que se llenen todos los demás. Si tiene muchos archivos pequeños, bueno, de todos modos tendrá una mesa grande (libreta de direcciones), así que también puede darles unidades pequeñas (casas).

Las unidades de asignación grandes, como regla general, desperdiciarán mucho espacio si tiene muchos archivos pequeños. Por lo general, no hay una buena razón para superar los 4 kB para uso general.

¿Fragmentación?

En cuanto a la fragmentación, la fragmentación no debería desperdiciar espacio de esta manera. Los archivos grandes pueden estar fragmentados, es decir, divididos en múltiples unidades de asignación, pero cada unidad debe llenarse antes de que se inicie la siguiente. La desfragmentación puede ahorrar un poco de espacio en las tablas de asignación, pero este no es su problema específico.

Soluciones posibles

Como sugirió gladiator2345 , sus únicas opciones reales en este momento son vivir con él o reformatearlo con unidades de asignación más pequeñas.

Su tarjeta puede estar formateada en FAT16, que tiene un límite más pequeño en el tamaño de la tabla y, por lo tanto, requiere unidades de asignación mucho más grandes para abordar un volumen mayor (con un límite superior de 2 GB con unidades de asignación de 32 kB). Fuente cortesía de Braiam . Si ese es el caso, debería poder formatear de forma segura como FAT32 de todos modos.

Esta es una de esas situaciones donde la compresión / archivo en un solo archivo puede ayudar. Lo que dijo Bob en su respuesta es cierto, pero la solución puede ser más fácil que reformatear el disco como sugieren otras respuestas. Si comprime o archiva el directorio (usando zip, tar o cualquier otro método), el sistema de archivos verá que tiene un solo archivo grande, en lugar de varios más pequeños. Incluso sin comprimir, recuperará casi 1,4 GiB de espacio, porque todos esos "archivos pequeños" se contarán como un solo archivo grande.

Dentro de esto, mi aplicación de mapas almacena sus mapas en caché y la aplicación obtiene su mapa de Google Maps

Tal vez debería hablar con el desarrollador para usar un archivo o una base de datos en lugar de varios archivos. Esto probablemente también ayudará a tener el disco menos fragmentado y seguramente ahorrará espacio, especialmente si se trata de una unidad flash NAND. Si explica la situación ridícula en la que 100 MB de carga útil / datos útiles se convierten en 1.4GiB, hay algo mal con la forma en que se almacenan los datos, y los desarrolladores deberían aportar una solución más agradable.

En caso de que alguien se enfrente a este problema, podría ser útil saber también que otra razón para ver una gran diferencia en el tamaño / espacio del archivo en el disco es el uso de flujos de datos alternativos (ADS)

Esto se aplica solo a NTFS, que yo sepa. Los ADS son conocidos para usos legítimos y no legítimos:

• para etiquetar un archivo como descargado de Internet
• para almacenar metadatos (Microsoft quería incluir algunas de las funciones del sistema operativo Apple, como no usar la extensión de archivo para determinar el tipo de archivo)
• para ocultar datos o código en el contexto de un malware .

ADS simplemente: cualquier archivo NTFS puede contener múltiples flujos de datos (entienda "subfiles"). Uno es la transmisión principal, utilizada por el Explorador de Windows y otras herramientas de Windows, contiene el contenido habitual de un archivo. Las secuencias de datos alternativas pueden contener otra información, exactamente como la secuencia principal, pero no pueden ser manejadas directamente por las herramientas de Windows (en particular, Explorer muestra el tamaño del archivo igual al tamaño de la secuencia principal, independientemente del tamaño de los ADS), debe usar herramientas especializadas o código para escribir, leer y ubicar ADS.

El punto principal es que en caso de que se observe una gran diferencia de tamaño de archivo, no pase por alto la posibilidad de ADS y malware oculto.

Otro vínculo .

Para experimentar de forma segura con ADS, intente esto a nivel de DOS / CMD ...

Cree y luego muestre el contenido de un archivo en la raíz de C:

C:\> echo The main data stream> test.txt
C:\> type test.txt

Resultado:

C:\> The main data stream

Ahora agregue un ADS con el mismo método, solo especifique el nombre ADS además del nombre del archivo:

C:\> echo The secret message> test.txt:secret

Acaba de ocultar el mensaje secreto en el archivo. Tenga en cuenta que el tamaño del archivo en Explorer no ha cambiado a pesar de que agregamos bytes en el "secreto" de ADS.

Intente mostrar el contenido de ADS:

C:\> type test.txt:secret

Resultado:

The filename, directory name, or volume label syntax is incorrect.

CMD typeno puede mostrar el contenido de los ADS. Utilizaremos el Bloc de notas en su lugar:

notepad test.txt:secret

En el Bloc de notas podemos ver el contenido de los ADS:

The secret message

También puede ocultar un archivo ejecutable completo en un ADS de un archivo de texto inocente y ejecutarlo en cualquier momento. La riqueza no perjudica a los piratas informáticos :-)

El problema puede deberse al tamaño del clúster.

De acuerdo con Microsoft :

Si no está utilizando la compresión NTFS para ningún archivo o carpeta contenida en el volumen, la diferencia entre TAMAÑO y TAMAÑO EN DISCO es el espacio desperdiciado debido a un tamaño de clúster mayor al necesario. Debe intentar usar un tamaño de clúster óptimo para que el valor de TAMAÑO EN DISCO sea lo más cercano posible al valor de TAMAÑO. Una discrepancia excesiva entre el TAMAÑO EN EL DISCO y el valor del TAMAÑO es una indicación de que el tamaño predeterminado del clúster es demasiado grande para el tamaño promedio de archivo que está almacenando en el volumen, y que debe reducirse. Esto se puede hacer solo haciendo una copia de seguridad del volumen y luego formateando el volumen utilizando el comando de formato y el modificador / a para especificar el tamaño de asignación apropiado: IE: format D: /a:2048 (Este ejemplo usa un tamaño de clúster de 2 KB).

Intente formatear su unidad con un tamaño de clúster más pequeño.

Veo a muchas personas que recomiendan reformatear su unidad con un tamaño de clúster más pequeño. Como se trata de una tarjeta SD, tenga en cuenta que muchos proveedores preformatean la tarjeta al tamaño de clúster recomendado para que coincida con el tamaño del clúster de NAND (mantener ambas sincronizadas es muy importante para un rendimiento óptimo de lectura / escritura y reducir el desgaste)

No puede cambiar el tamaño del clúster de NAND (es un atributo físico del hardware de su tarjeta SD).

Primero ejecute scandisk / chkdsk en su tarjeta SD para asegurarse de que el problema del informe de tamaño no se encuentre dentro de un sistema de archivos dañado.

En segundo lugar, le sugiero que informe el error a los desarrolladores de Google Map, ya que ellos son los culpables aquí. Deberían estar utilizando un método de almacenamiento superior. Arreglarlo también debería hacer que la aplicación se ejecute más rápido en muchos dispositivos debido a la menor actividad de E / S y del controlador del sistema de archivos.

Este es un problema general con muchos sistemas de archivos. Aquí hay dos factores en juego: la cantidad máxima de "bloques" que un sistema de archivos puede manejar por volumen lógico y las restricciones físicas del medio de almacenamiento. Solo se puede asignar 1 archivo a cualquier bloque dado (los archivos generalmente toman tantos bloques como sea necesario). Por lo tanto, un archivo de texto con 64 bytes a menudo puede tomar desde 4k hasta 32k, dependiendo del tamaño de bloque del sistema de archivos en el que reside.

Una forma de pensar en esto es pensar en cada bloque en el sistema de archivos como una caja, y el sistema de archivos como una habitación. Todas sus cajas son del mismo tamaño, e intenta colocar tantas como pueda en una habitación. Si los acomodas a todos con más espacio sobrante, tienes que obtener cajas más grandes para que la habitación se llene completamente de cajas.

Una de las reglas para poner cosas en cajas es que no se pueden poner dos cosas no relacionadas en una caja. Tienen que ser parte del mismo documento. Entonces, si escribiera una página de texto, tendría su propio cuadro. Si mi texto escrito tuviera tantas páginas que no podría incluirlo todo en un cuadro, simplemente encontraría otro cuadro y continuaría colocando páginas allí, repitiendo hasta que haya archivado todas mis páginas. También habría escrito los cuadros que había usado para ese documento y el orden de los cuadros para leerlos en secuencia.

Dependiendo de cómo organizaría las cajas, es posible que solo tenga suficiente espacio en mi manifiesto para un cierto número de cajas. Entonces, si tuviera una habitación grande para llenar, pero solo una pequeña cantidad de cajas, tendría que usar cajas muy grandes para alcanzar la capacidad de la habitación.

Entonces, en ese caso, mi documento de una página todavía ocuparía una sola caja, sin nada más que compartirlo.

Las mismas situaciones se desarrollan entre varias soluciones de almacenamiento. FAT32 solo puede administrar lo que se considera un bajo número de "cajas" en los enormes discos duros de la actualidad, por lo que termina con "cajas" muy grandes para compensar esto.

Además de los tamaños de clúster, también puede tener una discrepancia debido a las siguientes condiciones:

• Los archivos comprimidos o encriptados pueden usar un espacio diferente al del tamaño de archivo lógico.
• Los archivos vinculados informarán n veces el número de enlaces multiplicado por el tamaño del archivo para el tamaño de archivo lógico, pero el espacio físico utilizado suele ser menor.

Debe echar un vistazo a la entrada de Subasignación de bloques en Wikipedia. Eso es exactamente lo que te está pasando. El uso de un sistema de archivos con soporte para Tail Packaging es una solución a nivel de sistema de archivos para este problema además de cambiar el tamaño del clúster de asignación.

Todos tienen el inconveniente de tener que volver a formatear el disco.

En algunos casos, simplemente almacenar esos archivos en un archivo solucionaría el problema (y los archivos pequeños también se comprimirían además de detener la pérdida de espacio al final de los archivos). Esto tiene el inconveniente de pasar algún tiempo descomprimido.

Otra opción si tiene tantos archivos pequeños debido a algún problema específico relacionado con la aplicación es almacenar sus datos de software utilizando otro método (puede estar en una base de datos). Pero, por supuesto, es una solución para programadores, no para usuarios finales.

http://en.wikipedia.org/wiki/Tail_packing

Noté grandes discrepancias de tamaño de archivo en Windows 10 en un archivo individual, pero si miro las propiedades del mismo archivo desde la misma ubicación (una unidad de red), con Windows XP, la gran discrepancia no existe; solo una pequeña diferencia, que es lo que esperarías. Creo que hay un error en Windows 10. Un archivo de 449 MB probablemente no ocupa 3.99 GB, que es lo que Windows 10 me dice.