GPT分区的分区表居然4K不对齐，PAT无法调整 怎么办？

once375ml

128MB   估计用起来没有区别  但是看着不爽

求大神支招

近2T的数据  倒腾完再重新分区是别想了

在MBR硬盘中，分区信息直接存储于主引导记录(MBR)中（主引导记录中还存储着系统的引导程序）。但在GPT硬盘中，分区表的位置信息储存在GPT头中。但出于兼容性考虑，硬盘的第一个扇区仍然用作MBR，之后才是GPT头。跟现代的MBR一样，GPT也使用逻辑区块地址（LBA）取代了早期的CHS寻址方式。传统MBR信息存储于LBA 0，GPT头存储于LBA 1，接下来才是分区表本身。64位Windows操作系统使用16,384字节（或32扇区）作为GPT分区表，接下来的LBA 34是硬盘上第一个分区的开始。为了减少分区表损坏的风险，GPT在硬盘最后保存了一份分区表的副本。与主启动记录 (MBR) 分区方法相比，GPT 具有更多的优点，因为它允许每个磁盘有多达 128 个分区，支持高达18 千兆兆字节的卷大小，允许将主磁盘分区表和备份磁盘分区表用于冗余，还支持唯一的磁盘和分区ID(GUID)。

以上是我网上翻到的一些资料

上文中提到了GPT起始于LBA 34  而我的硬盘的这个128分区正是起始于34  所以这是标准结构 然后对其就别想了？？？？

once375ml

dream2627 发表于 2014-1-7 08:56
格式化的时候,选择一下簇吧,看看哪个簇可以对应4K对齐

windows 7 分区会自动对其

我试过了   这个 128MB的GPT隐藏分区  是win 7下硬盘初始化GPT分区自动生成的

然后了分了个80G的系统分区 准备EFI启动 然后后面的额2.xT 是数据  这两个分区都是对齐的

once375ml

dream2627 发表于 2014-1-7 09:24
我之前格式化SSD的一个分区,选32K和16K簇格式化都没办法4K对齐,后来格式化成4096字节和8192字节,才对齐了4K

可能你没听我说明白 我查了 可能规范就是这样的

传统MBR信息存储于LBA 0，GPT头存储于LBA 1；64位Windows操作系统使用16,384字节（或32扇区）作为GPT分区表
也就是说这个0-33扇区的是无法对齐的 因为34/4 无法整除，也就导致了紧随其后的128MB GPT隐藏分区也无法对齐，这个128MB 是用来装各种系统的引导文件（例如64位的windows 7的引导文件 支持GPT的Linxu系统引导文件）  而 剩下的空间 如果用window 7分区 则是会自动对齐的


SSD对齐  效果明显，而且也必须对齐 不然会有写放大

HDD对齐   能提升5%-10%的性能

二代战神

楼主直接diskpart看一下

once375ml

二代战神 发表于 2014-1-7 12:45
楼主直接diskpart看一下

看了   第二 三分区 是对齐的

第一个分区 就是那个128M的GPT隐藏分区  是不对齐的 但是这都是windows 7 直接操作的结果

接受这个现实吧  就这样了

二代战神

once375ml 发表于 2014-1-7 15:04
看了   第二 三分区 是对齐的

第一个分区 就是那个128M的GPT隐藏分区  是不对齐的 但是这都是windows  ...

除非你自己设偏移量 否则不可能出现第一个分区不对齐后面的反倒能对齐

once375ml

二代战神 发表于 2014-1-9 14:35
除非你自己设偏移量 否则不可能出现第一个分区不对齐后面的反倒能对齐

解决了  在uefi 启动的PE下 安装uefi windows 8.1   删除所有非数据分区了 让系统自动分区  分出来的都是完美的4K对齐

但是蛋疼是装机箱是 貌似主板被击穿了 冬天 毛衣  伤不起啊

msg7086

UEFI顶头的一个隐藏分区本身就是空白分区。

我记得UEFI有规定不允许分区与分区之间有空白 (free space)，所以微软默认会创建一个不能使用也不能访问的空分区，来代替空白空间，这个分区自己不对齐，但是可以用来帮助后续分区对齐。

如果这个分区完美对齐了，那多数可能性是分区头部还是有空白空间，可能会造成和一些UEFI设备不兼容。当然如果你用着没问题的话也无所谓就是了……

once375ml

azure911 发表于 2014-1-14 14:09
也就是说这个128M的不对齐无关紧要咯

对齐 对于SSD很重要

我这个是HDD  对不对齐不重要 我只是想分区分的完美点

至于这个MSR的128M分区 系统基本不常读写  应该影响不大

偶要减肥

很多小白根本不会看