OT – Parted Guidance

Home » CentOS » OT – Parted Guidance
CentOS 8 Comments

Hi All, Slightly OT as this is on a CentOS 6 system

I’m getting the fdisk message “partition does not start on a physical sector boundary” on a 4096 sector disk. I understand why this has happened.

I just want to be sure of my parted syntax before I really mess things up. (before anyone says it – I know – do a backup)

parted says that the offending partition 5 begins at 512 byte sector no.
462999615. Its the first partition in the extended partition that begins at 462999552.

If I just want to move the partition back to the nearest 4096 boundary, which is 462999608, would the syntax be

unit s move 5 462999608

Will parted sort itself out copying sector nos 462999615 to 462999608
and then 462999616 to 462999609 and on an on? Or will it not cope with jiggling the partition down the disk by 7 sectors?



8 thoughts on - OT – Parted Guidance

  • Ken Smith wrote:
    Not at all OT. We started using parted when we started using 3TB drives a few years ago, since fdisk can’t handle > 2TB.

    Wait, you’re resizing a partition? I don’t know if I’d want to do that with data there, unless you were *SURE* there was nothing in that area.

    For future reference, when I partition a disk, I start parted with -a opt, to make sure it knows in advance that I want optimal alignment, then, as an example, if I’m partitioning a large drive, I do this:
    mklabel gpt mkpart pri xfs 0.0GB 100%
    and it’s aligned properly. I discovered some time back that using the x.0GB syntax got parted to align it correctly, and it doesn’t complain.

    mark “parted: user surly”

  • m.roth@5-cent.us wrote:

    Thanks Mark – What I’d like to try to do is correct my earlier error by moving the partition 7/8ths of a 4096 sector down the disk. IE: 7 x 512
    byte ‘virtual’ sectors. To get the beginning of partition 5 on to a 4096
    sector boundary.

    This disk was copied with dd from an original disk that has 512 byte
    ‘real’ sectors. Hence the misalignment.

    Parted says that the extended partition begins at sector 462999552 (in
    512 byte sector speak). Currently it says that the first extended partition (partition 5) starts at 462999615 which is 7 sectors beyond a
    4096 sector boundary at 462999608.

    I take your point about what’s between 462999552 and 462999615 (63
    sectors), and the risk of overwriting something important. If I reduce that space to 56 sectors would I overwrite any partition table data related to the extended partition? I know that extended partitions have a linked list of extended boot records that I believe are 1 x 512 byte sector long. This describes the basic structure https://en.wikipedia.org/wiki/Extended_Boot_Record

    My real question was whether my syntax to parted was right. Man pages I
    have seen say this

    move partition start end

    and examples I’ve seen on the web show “start” in MBytes. I want to be sure that the move command obeys the unit setting. If it interprets my start in the “move 5 462999608” as MBytes I’ll most likely need my backup!



  • What filesystem is on that partition? For anything other than the FAT
    variants, you’ll find parted is hopelessly crippled for moving or resizing partitions. And, you would have to use “resize” since parted cannot move a partition onto itself.

  • The problem with gparted is that it works only in units of megabytes. There is no way to move a partition to a particular sector or, for that matter, do much of anything _exactly_.

  • I’m not sure why granularity finer than 1MiB is necessary. But setting that aside, with a rotational drive with 4KiB sectors, you’re better off with 1MiB alignment than not being 4KiB aligned at all. Depending on the drive and workload misalignment can cause a brutally bad performance hit. And if it doesn’t then I wouldn’t worry about changing anything.

  • Chris Murphy wrote:
    Thanks everyone. That’s the advice I need. The partition is ext4. I’ll copy it to other media and rearrange the partitions and copy it back.


  • Am 02.08.2015 um 19:12 schrieb Ken Smith :

    the alignment can be checked with:

    blockdev –getalignoff /dev/foo

    if a ‘0’ is returned, the partition is aligned