Con muchos discos duros nuevos, el tamaño del sector físico es 4096. ¿Sería posible hacer que el sistema utilice un tamaño de sector lógico del mismo tamaño, en lugar del tamaño de sector lógico predeterminado de 512?
¿Acelerará las lecturas y escrituras masivas? ¿Dónde se puede configurar?
Respuestas:
512 bytes no es realmente el tamaño de sector predeterminado. Depende de tu hardware.
Puede mostrar qué tamaños de sector físico / lógico informa su disco a través del /syspseudo sistema de archivos, por ejemplo:
# cat /sys/block/sda/queue/physical_block_size
4096
# cat /sys/block/sda/queue/logical_block_size
512
¿Cuál es la diferencia entre esos dos valores?
physical_block_sizees el tamaño mínimo de un bloque de la unidad es capaz de escribir en una operación atómica.logical_block_sizees el tamaño más pequeño de la unidad es capaz de escribir (véase la documentación del núcleo Linux).Por lo tanto, si tiene una unidad de 4k, tiene sentido que su pila de almacenamiento (sistema de archivos, etc.) use algo igual o mayor que el tamaño del sector físico.
Esos valores también se muestran en versiones recientes de fdisk, por ejemplo:
# fdisk -l /dev/sda
[..]
Sector size (logical/physical): 512 bytes / 4096 bytes
En las distribuciones actuales de Linux, los programas (que deberían preocuparse por el tamaño óptimo del sector) mkfs.xfselegirán el tamaño óptimo del sector de forma predeterminada (por ejemplo, 4096 bytes).
Pero también puede especificarlo explícitamente a través de una opción, por ejemplo:
# mkfs.xfs -f -s size=4096 /dev/sda
O:
# mkfs.ext4 -F -b 4096 /dev/sda
En cualquier caso, la mayoría de las mkfsvariantes también mostrarán el tamaño de bloque utilizado durante la ejecución.
Para un sistema de archivos existente, el tamaño del bloque se puede determinar con un comando como:
# xfs_info /mnt
[..]
meta-data= sectsz=4096
data = bsize=4096
naming =version 2 bsize=4096
log =internal bsize=4096
= sectsz=4096
realtime =none extsz=4096
O:
# tune2fs -l /dev/sda
Block size: 4096
Fragment size: 4096
O:
# btrfs inspect-internal dump-super /dev/sda | grep size
csum_size 4
sys_array_size 97
sectorsize 4096
nodesize 16384
leafsize 16384
stripesize 4096
dev_item.sector_size 4096
Al crear el sistema de archivos en una partición, otra cosa a verificar es si la dirección de inicio de la partición está realmente alineada con el tamaño del bloque físico. Por ejemplo, mire la fdisk -lsalida, convierta las direcciones de inicio en bytes, divídalas por el tamaño del bloque físico; el recordatorio debe ser cero si las particiones están alineadas.
fdisk -l, la dividí entre 8 y luego 512. el resto no era 0, por lo que la partición parece no estar alineada
fdisk -linforma Units = sectors of 1 * 512 = 512 bytesen uno de mis sistemas Linux, por lo tanto, para una unidad lógica / física 512/4096 con 2 particiones a partir de 2048 y 1026048 calculo 2048*512%4096y 1026048*512%4096, por ejemplo, en un shell de Python. Como ambas expresiones son iguales a cero, esas particiones están alineadas 4k.
No, no es posible, ni importaría si lo fuera. IO generalmente se realiza en unidades de al menos 4096 bytes de todos modos, y generalmente mucho más.
Sí, es posible, sin embargo, al hacerlo, la unidad se llenará mucho más rápido de lo que debería. Para archivos de menos de 512K, cada archivo ocuparía un total de 4096K (4MB) y llenaría el resto del sector con 0 debido a la incapacidad de la mayoría de los sistemas de archivos (NTFS y similares) para permitir que los archivos compartan sectores. La mejor opción para un sistema de archivos sería permitir tamaños de sector variables, sin embargo, esto aumenta el tamaño de la MFT (tabla maestra de archivos) y aumenta el riesgo de corrupción de datos al tiempo que reduce la capacidad de recuperar datos fácilmente. En otras palabras, los límites no serían completamente conocidos por el software de recuperación. Entonces, si bien un tamaño de sector lógico de 4096K es increíble para archivos grandes, para una PC normal de uso diario, es solo un montón de ceros. Ahora, con eso dicho, existe la opción de almacenar datos en la propia MFT cuando se trata de datos más pequeños que el tamaño del sector lógico. Esto, sin embargo, significa que su MFT se vuelve enorme y los datos se escribirían dos veces (hay dos copias de la MFT en su HDD). También tendría que especificar el tamaño máximo de la MFT, lo que puede causar problemas cuando alcanza su máximo o el uso de la unidad excede lo que la MFT podría usar. Todo esto se basa en el uso de un sistema de archivos NTFS. En el lado positivo de las cosas, NTFS le permite usar compresión nativa para archivos en el nivel de bloque para cualquier tamaño de sector lógico de 4 MB o menos. Esta limitación se aplica debido a la forma en que funciona la compresión NTFS. Los bloques de 4 MB se leen y comprimen independientemente del tamaño del sector lógico. Esto, por supuesto,
Entonces, ¿esto te aclara un poco las cosas?
Sector:
1) Logical Sector: Called Native Sector.
Manufacture default setting. user cannot change.
Before 2010 year: 512b/sector
After 2010 year: 4k/sector.
Few manufacture provide HDD tool to change native sector.
2) Physical Sector: Called Cluster(or allocation unit - FAT windows) or Block(Linux/Unix)
User can change physical sector size 512b,1k,2k,4k,... by format or partition tool. Physical sector contains one or few more native sectors.
(example1: if you have HDD 512b/native sector: user can set 4K/Physical sector. this mean 1 cluster = 4 native sector)
(example2: if you have HDD 4K/native sector: user can set 4K/Physical sector. this mead 1 cluster = 1 native sector)
3) File system deal with Physical sector(or block or Cluster) only.
mkfs.*deberían usar automáticamente el tamaño de sector óptimo. Puede hacer algunasmkfs.*pruebas e inspeccionar el resultado (ya sea en la salida detallada de mkfs o en un programa de utilidad fs relacionado).