Debian – How to Force Physical Sector Size on a Hard Disk

I've seen a few 4Kn SATA drives working in the hard drive validation industry, but I wasn't aware they were shipping any to customers, due to the limited hardware and software support for them and lack of customer demand.

There are two competing mappings for physical vs. logical sector sizes. The Long Logical Sector feature allows a device to have logical sectors longer than 512B (e.g. 4Kn), and the Long Physical Sector feature allows a device to have multiple logical sectors per physical sector (e.g. 512e), though they are not necessarily mutually exclusive. If the manufacturer is claiming the drive is 4Kn, the older controller may providing an emulation layer, like read-modify-write, for older applications and hardware, as older systems simply don't support the 4Kn format.

The sg_sat_identify command from the sg3_utils package would probably give you the information you need (check words 106-108 for Physical sector size/logical sector size information).

It doesn't look like SATA drives can support emulation on-demand, per se, but if the drive is indeed using 512e, instead of 4Kn, performance optimization is maximized by the driver (or possibly USB SATA controller) limiting reads/writes to 4K boundaries, e.g. having the transfer start on an LBA where the lower 3 bits are 0, and end on an LBA where the lower 3 bits are 1:

start_lba & 0x3 == 0
end_lba & 0x3 == 1

So, basically, there's no "switch" that can tell the drive to start or stop emulation. From an end-user perspective, your best bet is probably to make sure your drives are using the best file system for whichever mapping your drive uses and to make sure it's aligned correctly. The following site gives a pretty good breakdown of the common file systems and their stats on performance vs. block alignment on different file systems: http://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/index.html

After struggling for a couple of hours, I solved it by myself. I'll post the solution here, just in case:

# Creates an empty disk image of 256MB, creates its GPT, and then it makes
# two partitions: the first one of approximatively 60MB, the second one fills
# the remaining bytes. Both partitions are aligned.
dd if=/dev/zero of=disk.img bs=1M count=256
parted disk.img
mktable gpt
mkpart primary fat32 2048s 131071s
mkpart primary fat32 131072s 100%
align-check optimal 1
align-check optimal 2
name 1 UEFI
name 2 SYSTEM
quit

# Creates an empty disk image of 33MB.
dd if=/dev/zero of=uefi.img bs=1M count=33
# Formats the disk image as FAT32
mkfs.vfat uefi.img -F 32
# Creates the requested subdirectories.
mmd -i uefi.img ::/EFI
mmd -i uefi.img ::/EFI/BOOT
# Copies the boot file.
mcopy -i uefi.img BOOTX64.EFI ::/EFI/BOOT

# Creates an empty disk image of 100MB.
dd if=/dev/zero of=system.img bs=1M count=100
# Formats the disk image as FAT32
mkfs.vfat system.img -F 32
# Copies the OS file.
mcopy -i system.img SYSTEM.EFI ::

# Enables the kernel module requested by kpartx, just in case.
sudo modprobe dm-mod
# Maps and mounts the two partitions in disk.img to /dev/mapper/loop0p1 and
# /dev/mapper/loop0p2
sudo kpartx -av disk.img
# Copies the UEFI partion into the disk image.
sudo dd if=uefi.img of=/dev/mapper/loop0p1 bs=1M
# Copies the SYSTEM partion into the disk image.
sudo dd if=system.img of=/dev/mapper/loop0p2 bs=1M
# Unmounts the two partitions
sudo kpartx -dv disk.img