Child pages
  • Larger sector size drives (4K and "Advanced Format")
Skip to end of metadata
Go to start of metadata

As drives sizes have grown, a need to increase the base sector size on disk has also grown. For a very long time the sector size (the smallest chunk a drive can read) has been set to 512 Bytes, with 2TB and beyond drives becoming available this is being increased to 4KiB (4096 bytes). As this would disrupt some old operating system, a standard has been developed that lets new OS use the real size of 4K whilst letting older OS's still use 512 Bytes with the drives firmware doing a conversion.

Unfortunately several drives have appeared that use 4KiB sectors, but which haven't implemented the standard and as such have to be explicitly marked as 4KiB to the OS or are used as if they are 512 Byte drive which can slow them down.


The workaround is a patch to the zpool command, which forces the ashift value to 12 (which internally represents 4KiB blocks). Some patches force this to 12 on all drives which is inefficient for 512 Byte drives. The patch here adds an optional block-size parameter.

Whilst this solution has not been extensively tested, it is being used with no known issues. But be warned this is not a supported workaround and unless speed is vital, you should consider using the standard OI support which has is stable, just not optimal in 4 KiB drives.

A drop in zpool replacement is here

The webrev with details of the patch applied to make the replacement zpool is here

The usage is zpool create tank block-size 4096 raidz1 drive1 drive2 drive3 drive4

There are efforts in Illumos to force ashift=12 via /kernel/drv/sd.conf, see

  • No labels


  1. Anonymous

    Most current (as of early 2011) available "Advanced Format" consumer hard drives are with 4KiB native sector size but appear to host OS as 512B/sector. This is called "512e" or "512-byte Emulation" drives. Native 4KiB drives without 512-byte emulation are hard to be found.

    512e drives are susceptible to two deficiencies. One is RMW (Read-Modify-Write) cycles inevitably due to emulation. The other is partition starting address alignment since the drives appear to be 512B/sector to host. Should partition and its meta data starts at non-aligned address (alignment should be 4KiB or 8 512B sectors) there will be performance degradation in addition to that of emulation.

    Might need fdisk and zpool/zfs to be able to handle alignment to mitigate the performance hit.

    1. My investigations seem to indicate that the OI format command already creates on the correct boundraries for 4KiB drives by default. If anyone finds any cases where it doesn't, please let me know :)

  2. Anonymous

    At this address there is a discussion about 4Kb drives and a zpool able to use them

    Good reading.

  3. Anonymous

    Is the zpool replacement still valid for OpenIndiana release 151a?

    1. It seems the zpool replacement is no longer on the web.  Both links listed here are dead.

      Anyone know where it may still exist? 

      1. I have the zpool-12 binary stashed in my archives, but it does not work anymore: zpool-12: fatal: relocation error: file /tmp/zpool-12: symbol zpool_set_history_str: referenced symbol not found Killed

        Googling shows that this happened back with oi151a6 already.

        Unfortunately, right now I'm stuck with an IDE disk (SATA in Legacy mode) and can't use the sd.conf tricks, apparently...