Primero, tenga en cuenta que el tamaño de bloque del dispositivo es diferente del tamaño de bloque que usa el sistema de archivos. El valor anterior según lo informado por diskutil se refiere al tamaño de bloque sin procesar usado por el hardware. No he encontrado una manera fácil de verificar este último valor mediante la línea de comandos, pero puede crear un archivo de cero bytes y luego obtener información del buscador. Dirá 0 bytes, pero 4k se utilizan en el disco.
En segundo lugar, puede crear un sistema de archivos HFS + con un tamaño de bloque superior a 4k utilizando el programa de línea de comandos newfs_hfs
. La forma más fácil es usar la Utilidad de Disco para particionar la unidad y crear una partición con el formato predeterminado, luego use /bin/df
para determinar el dispositivo de bloque (solo un ejemplo: /dev/disk0s2
). Luego desmonte esa partición (usando umount /dev/diskXXX
o Utilidad de Disco), y para volver a formatear como HFS + con 64k bloques, haga lo siguiente:
newfs_hfs -v VolumeName -b 65536 /dev/disk0s2
Use la sugerencia Obtener información anterior para verificar que un archivo pequeño ahora ocupa 64k en el disco (puede decir 65k para potencias de 10 unidades).
El rendimiento es la razón principal por la que podría querer hacer esto, si la mayoría de los datos que se almacenarán son archivos grandes (como MP3, fotos, videos, archivos .zip, etc.) y también ayuda a mantener la fragmentación del disco. bajo. Obviamente, no te preocupes si planeas almacenar principalmente archivos pequeños.
Descubrí que en unidades grandes (> 1 TB) formateadas como HFS con el tamaño de bloque predeterminado de 4k, cuando la unidad se acerca a su capacidad, el rendimiento de escritura se degrada considerablemente. Supongo que esto se debe a que la partición está fragmentada y hay que buscar y buscar bloques libres para escribir el último 1% de los datos. Espero que los bloques de mayor tamaño alivien un poco este problema.