With many new hard drive disks the physical sector size is 4096. Would it be possible to make the system use a logical sector size of the same size, rather than the default logical sector size of 512?
Will it speed up bulk reads and writes? Where can it be configured?
512 byte is not really the default sector size. It depends on your hardware.
You can display what physical/logical sector sizes your disk reports via the /sys pseudo filesystem, for instance:
# cat /sys/block/sda/queue/physical_block_size
4096
# cat /sys/block/sda/queue/logical_block_size
512
What is the difference between those two values?
physical_block_size is the minimal size of a block the drive is able to write in an atomic operation.logical_block_size is the smallest size the drive is able to write (cf. the linux kernel documentation).Thus, if you have a 4k drive it makes sense that your storage stack (filesystem etc.) uses something equal or greater than the physical sector size.
Those values are also displayed in recent versions of fdisk, for instance:
# fdisk -l /dev/sda
[..]
Sector size (logical/physical): 512 bytes / 4096 bytes
On current linux distributions, programs (that should care about the optimal sector size) like mkfs.xfs will pick the optimal sector size by default (e.g. 4096 bytes).
But you can also explicitly specify it via an option, for instance:
# mkfs.xfs -f -s size=4096 /dev/sda
Or:
# mkfs.ext4 -F -b 4096 /dev/sda
In any case, most mkfs variants will also display the used block size during execution.
For an existing filesystem the block size can be determined with a command like:
# 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
Or:
# tune2fs -l /dev/sda
Block size: 4096
Fragment size: 4096
Or:
# 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
When creating the filesystem on a partition, another thing to check then is if the partition start address is actually aligned to the physical block size. For example, look at the fdisk -l output, convert the start addresses into bytes, divide them by the physical block size - the reminder must be zero if the partitions are aligned.
fdisk -l, divided it by 8 and then 512. The remainder wasn't 0, so the partition seems to be not aligned
fdisk -l reports Units = sectors of 1 * 512 = 512 bytes in one of my Linux systems - thus, for a 512/4096 logical/physical drive with 2 partitions starting at 2048 and 1026048 I compute 2048*512%4096 and 1026048*512%4096 - e.g. in a python shell. Since both expressions equal zero those partitions are 4k aligned.
Mar 11, 2019 at 16:49
No, it is not possible, nor would it matter if it were. IO is typically done in units of at least 4096 bytes anyhow, and usually much more.
Yes it is possible, however doing so would cause the drive to fill much quicker than it should. For files less than 512K, each file would then take up a full 4096K (4MB) and fill the rest of the sector with 0's due to the inability for most filesystems (NTFS and the like) to allow files to share sectors. The best option for a filesystem would be to allow variable sector sizes, however this increases the size of the MFT (master file table) and increases the risk of data corruption while reducing the ability to recover data easily. In other words, the boundaries would be not entirely known by the recovery software. So, while a 4096K logical sector size is awesome for large files, for a normal everyday use PC, it's just a bunch of 0's. Now, with that said, there is the option of storing data in the MFT itself when it comes to data smaller than the logical sector size. This, however, means that your MFT becomes huge and data would be written twice (there are two copies of the MFT on your HDD). You would also have to specify the maximum size of the MFT which can cause for problems when either you reach its maximum or the drive usage exceeds what would be free for the MFT to use. All of this is based on the usage of an NTFS file system. On the brighter side of things, NTFS does allow you to use native compression for files at the block level for any logical sector size of 4MB or less. This limitation is applied due to the way in which the NTFS compression works. 4MB blocks are read and compressed regardless of the logical sector size. This, of course, cannot occur for anything larger than 4MB in sector size due to it then crossing boundaries and losing data.
So, does this clear things up for you a bit?
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.*should automatically use the optimal sector size. You can do somemkfs.*tests and inspect the result (either in the verbose output of mkfs or in a related fs utility program).