Primero, tenga en cuenta que el tamaño de bloque del dispositivo es diferente del tamaño de bloque en uso por el sistema de archivos. El valor anterior según lo informado por diskutil se refiere al tamaño de bloque sin procesar utilizado por el hardware. No he encontrado una manera fácil de verificar el último valor por la línea de comando, pero puede crear un archivo de cero bytes y luego obtener información del buscador. Dirá 0 bytes, pero se usaron 4k en el disco.
En segundo lugar, puede crear un sistema de archivos HFS + con bloques de más de 4k utilizando el programa de línea de comandos newfs_hfs
. La forma más fácil es usar la Utilidad de Discos para particionar la unidad y crear una partición con el formato predeterminado, luego usar /bin/df
para determinar el dispositivo de bloqueo (solo un ejemplo:) /dev/disk0s2
. Luego desmonte esa partición (usando umount /dev/diskXXX
o la Utilidad de Discos), y para formatear como HFS + con bloques de 64k:
newfs_hfs -v VolumeName -b 65536 /dev/disk0s2
Use el consejo Obtener información anterior para verificar que un archivo pequeño ahora ocupa 64k en el disco (puede decir 65k para unidades de potencia de 10).
El rendimiento es la razón principal por la que puede 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 baja la fragmentación del disco. Obviamente, no te molestes si planeas almacenar principalmente archivos pequeños.
He encontrado que en unidades grandes (> 1 TB) formateadas como HFS con el tamaño de bloque predeterminado de 4k, cuando la unidad se acerca a la capacidad, el rendimiento de escritura se degrada terriblemente. Supongo que eso se debe a que la partición está fragmentada y tiene que buscar y picotear bloques libres para escribir el último 1% de los datos. Espero que los tamaños de bloque más grandes alivien un poco este problema.