Recent Changes - Search:



My journals will take the place of a blog. They have moved to

Sites I take responsibility for






Places I frequent



Items for sale:


edit SideBar

GNU Parted

Include our styles below Infobox - invoke as >>infobox<< ... >><<

Codebox: - invoke as >>codebox<< ... >><<

warnbox: - invoke as >>codebox<< ... >><<

editingbox: - invoke as >>codebox<< ... >><<

noticebox: - invoke as >>codebox<< ... >><<

Page bread crumbs:

Pages by tags: (:listtags:)
Subscribe to this wiki: RSS Feed RSS or subscribe to this page for changes: RSS Feed RSS
496 articles have been published so far. Recent changes
(:addThis btn="custom":)

Main page for gparted -

This page references the command line tool as opposed to the graphical application: GParted

Docs: at and

Linux: You have to use gparted command instead of fdisk for GPT partitions and you need GPT partitions for volumes ov er 2TiB in size.

Alignment issues:

You may get complaints about alignment.

"The resulting partition is not properly aligned for best performance"

Use command:

(:code:) $ sudo parted -a optimal /dev/xvdf mkpart test "0%" "100%" (:codeend:)

See also HP Tech Doc on this: and also this blog post:

Recent enhancements to the SCSI and ATA standards allow storage devices to indicate their preferred (and in some cases, required) I/O alignment and I/O size. This information is particularly useful with newer disk drives that increase the physical sector size from 512 bytes to 4k bytes. This information may also be beneficial for RAID devices, where the chunk size and stripe size may impact performance.

The Linux I/O stack has been enhanced to process vendor-provided I/O alignment and I/O size information, allowing storage management tools (parted, lvm, mkfs.*, and the like) to optimize data placement and access. If a legacy device does not export I/O alignment and size data, then storage management tools in Red Hat Enterprise Linux 6 will conservatively align I/O on a 4k (or larger power of 2) boundary. This will ensure that 4k-sector devices operate correctly even if they do not indicate any required/preferred I/O alignment and size.

Note: Red Hat Enterprise Linux 6 supports 4k-sector devices as data disks, not as boot disks. Boot support for 4k-sector devices is planned for a later release. Refer to Section 18.2, “Userspace Access” to learn how to determine the information that the operating system obtained from the device. This data is subsequently used by the storage management tools to determine data placement.

Parameters for Storage Access:

The operating system uses the following information to determine I/O alignment and size:

  • physical_block_size - Smallest internal unit on which the device can operate
  • logical_block_size - Used externally to address a location on the device
  • alignment_offset - The number of bytes that the beginning of the Linux block device (partition/MD/LVM device) is offset from the underlying physical
  • alignment - minimum_io_size - The device’s preferred minimum unit for random I/O
  • optimal_io_size - The device’s preferred unit for streaming I/O

For example, certain 4K sector devices may use a 4K physical_block_size internally but expose a more granular 512-byte logical_block_size to Linux. This discrepancy introduces potential for misaligned I/O. To address this, the Red Hat Enterprise Linux 6 I/O stack will attempt to start all data areas on a naturally-aligned boundary (physical_block_size) by making sure it accounts for any alignment_offset if the beginning of the block device is offset from the underlying physical alignment.

Storage vendors can also supply I/O hints about the preferred minimum unit for random I/O (minimum_io_size) and streaming I/O (optimal_io_size) of a device. For example, minimum_io_size and optimal_io_size may correspond to a RAID device's chunk size and stripe size respectively.

Userspace Access:

Always take care to use properly aligned and sized I/O. This is especially important for Direct I/O access. Direct I/O should be aligned on a logical_block_size boundary, and in multiples of the logical_block_size. With native 4K devices (i.e. logical_block_size is 4K) it is now critical that applications perform direct I/O in multiples of the device's logical_block_size. This means that applications will fail with native 4k devices that perform 512-byte aligned I/O rather than 4k-aligned I/O. To avoid this, an application should consult the I/O parameters of a device to ensure it is using the proper I/O alignment and size. As mentioned earlier, I/O parameters are exposed through the both sysfs and block device ioctl interfaces.

For more details, refer to man libblkid. This man page is provided by the libblkid-devel package.

sysfs Interface:

  • /sys/block/disk/alignment_offset
  • /sys/block/disk/partition/alignment_offset
  • /sys/block/disk/queue/physical_block_size
  • /sys/block/disk/queue/logical_block_size
  • /sys/block/disk/queue/minimum_io_size
  • /sys/block/disk/queue/optimal_io_size

The kernel will still export these sysfs attributes for "legacy" devices that do not provide I/O parameters information, for example:

(:code:) alignment_offset: 0 physical_block_size: 512 logical_block_size: 512 minimum_io_size: 512 optimal_io_size: 0 (:codeend:)

Block Device ioctls

  • BLKALIGNOFF: alignment_offset
  • BLKPBSZGET: physical_block_size
  • BLKSSZGET: logical_block_size
  • BLKIOMIN: minimum_io_size
  • BLKIOOPT: optimal_io_size

Some good articles I came across:

Kevin's Public Wiki maintained and created by Kevin P. Inscoe is licensed under a
Creative Commons Attribution 3.0 United States License.

Back to my web site -

Edit - History - Print - Recent Changes - Search
Page last modified on August 14, 2015, at 07:19 PM EST