# Parititon Tables and Alignment [SOLVED]

## justin_brody

Hello,

I've seen some stuff about this issue elsewhere on the net, but I didn't quite follow the details.

I'm trying to set up a partition scheme on my hybrid ssd drive.  I'd already installed gentoo on /dev/sda3, so I used systemrescuecd to used gparted on the drive.  It  seemed to shrink sda3 down o.k. and create all the new partitions I wanted.   When I rebooted, I get the following error from fdisk:

```

 # fdisk  /dev/sda

The device presents a logical sector size that is smaller than

the physical sector size. Aligning to a physical sector (or optimal

I/O) size boundary is recommended, or performance may be impacted.

Welcome to fdisk (util-linux 2.22.2).

```

Here's the table:

```

# fdisk -lu /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk identifier: 0xb2dd36f8

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1       648673280   751073279    51200000    7  HPFS/NTFS/exFAT

/dev/sda2       751073280   976773119   112849920    5  Extended

/dev/sda3        34273280   648673279   307200000   83  Linux

/dev/sda4            2048    34273279    17135616   82  Linux swap / Solaris

/dev/sda5       955877376   976773119    10447872    7  HPFS/NTFS/exFAT

/dev/sda6       751075328   767459327     8192000   83  Linux

/dev/sda7       767461376   955875327    94206976   83  Linux

```

What I saw elsewhere indicated that the start sectors needed to be divisible by 8, mine all are.

Running cfdisk returns this:

```
FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap

```

Any help greatly appreciated!Last edited by justin_brody on Sat Jan 04, 2014 6:23 pm; edited 1 time in total

----------

## NeddySeagoon

justin_brody,

Your HDD tells the operating system that it has 512B sectors. It doesn't really, they are 4096B. Thus 4096B is the smallest unit that can be read or written from your drive.

However, to meet the claim of 512B sectors, the drive will read  4096B, change the 512B that needs to be changed in the block, then write the updated  4096B back to the drive.  This process is slow as it needs two disc accesses.

By making partitions misaligned, not starting on a multiple 8 sectors, you ensure that misaligned access happen a lot.

The multiple of 8 is just 4096/512.

Sorting your partition table by start block order for easy reading gives

```
   Device Boot      Start         End      Blocks   Id  System

/dev/sda4            2048    34273279    17135616   82  Linux swap / Solaris

/dev/sda3        34273280   648673279   307200000   83  Linux

/dev/sda1       648673280   751073279    51200000    7  HPFS/NTFS/exFAT

/dev/sda2       751073280   976773119   112849920    5  Extended

/dev/sda6       751075328   767459327     8192000   83  Linux

/dev/sda7       767461376   955875327    94206976   83  Linux 

/dev/sda5       955877376   976773119    10447872    7  HPFS/NTFS/exFAT
```

I see some wasted space but no overlaps

----------

## justin_brody

Neddy,

Thanks so much for this lucid explanation, and for taking the time to look closely at my partition table!

A couple of follow-up questions:

 Is there any sense in trying to make the logical and physical numbers match?  Can I even do that?

 Assuming that the file system needs to change all 4K, can it do that in a single read/write or does it have to do it 8 separate times?

Thanks again for your help!

----------

## NeddySeagoon

justin_brody,

The kernel block device driver keeps a cache, which it flushes to disk every so often.

Times vary from filesystem to filesystem.  The disk will actually commit the data in as few writes as it can.

If you write 16kB and the write is aligned and sequential, thats effectively one write.

If its 16kB aligned and scattered, its at most four writes.

For 16kB misaligned and scattered, thats 8 read/modify/writes

----------

## Navar

 *justin_brody wrote:*   

> Is there any sense in trying to make the logical and physical numbers match?  Can I even do that?

 

Yes and Neddy's explanation gave reasons.  Basically you're fighting with the industry's version of a marketing logistics band-aid in an effort to substantially cheapen the logic cost per sector on larger density devices (usually 1TB+).  They provided firmware logic to continue working transparently to the end user with partition tools, etc. that have been used to the standard 512 byte sector size for many decades.  The problem is these stop-gap measures cause performance issues.  Internally the drive is now really 4096 layout, but supporting firmware translation to external connections as still being 512.

On your second question, yes, but it can be somewhat troublesome.  If all your partitions were Linux type, it'd be mostly trivial (with respect to any changed UUID usage in boot loader/fstab) with full backups and restore after re-creating/aligning the partitions, ideally with 1MiB alignment.  In your example given, the starting offset of /dev/sda4 is already partitioned the way you'd want.  The 2048 starting position is actually referencing a 512 byte sector size or = 1048576 which is usually plenty of room for a boot loader.  Nothing in linux cares about your offset locations changing other than in finding a particular filesystem, either in a more traditional way via dev file system mapping on a block device, e.g. /dev/sda3, or via a UUID mapping.

Windows boot partitions, on the other hand, start to throw expectations and assumptions into the mix.  I'm going by memory on dealing with an 'Advanced Format' drive over a year ago with the now common on large size drives, SSDs, etc. as a logical/physical mixture of 512/4096b sector size.  Eventually industry will force a transition entirely to 4096 size as a further cost reduction.  The Windows XP and older boot environments are not as picky and will generally just work as long as the unique partition ID wasn't modified (there are ways around that too).  You can shift starting partition offsets with usually little trouble.  If you're using Vista+, there's a strong chance you would need to fight with some Windows registry entries (via linux and not so trivial) and use the Windows PE boot repair tool.  This may cause additional (re)activation headaches once bootable.

If neither NTFS partition listed is for booting into Windows, then things become much easier.  Since /dev/sda1 in your case seems to be the only primary partition that is NTFS, I'd suspect that was a windows boot partition.  The fact that it seems to mapped to sda1 but a high offset value with 2 linux partitions coming before it implies having been moved before, perhaps by another linux distro installer.  /dev/sda5 is within your extended partition space, so I'll presume that was just extra storage formatted in windows.  Some of your partitions have a 2048x512=1MiB sector gap between them, some are immediate with no gap (sda4->sda3 e.g.).  The gap isn't 'necessary' but may be important for performance reasons, particularly in the newer 4096 formats.  Why gparted may offset by 2049 instead of 1 for another MiB boundary is perhaps a bug, not certain.  On a 1TB drive I haven't missed the unallocated MB per partition gap to fight with shifting things back.

Once you've backed up the entire drive, a fairly safe way to do the heavy lifting for you is to use a rescue type CD/USB that has GParted for partition changes (such as moving/resizing).  This will retain UUIDs set in your existing partitions but will not magically resolve windows Vista+ registry and activation protection mechanisms in their pre-boot environment which track a particular prior partition offset value.

----------

## Navar

justin_brody,

Sorry, I should have re-read your original message.  You mentioned it's an SSD and I realize many are going to 8KiB sizes instead of 4 as part of the arguments for using 1MiB boundaries.

Your starting offsets are all divisable by 8 and 2048.  So you're fine, stop there!  :Wink: 

----------

