Chinaunix

标题: 求助..谁知道在linux下怎么挂上3tb的外设. [打印本页]

作者: kabir 时间: 2005-12-10 18:25
标题: 求助..谁知道在linux下怎么挂上3tb的外设.
求助..谁知道在linux下怎么挂上3tb的外设.
只分一个区..我分的时候最大能分到1.4tb求助..谁知道在linux下怎么挂上3tb的外设.

作者: nntp 时间: 2005-12-10 21:58
怎么会?

描述一下你的环境先 !!!!!

1. linux 版本, kernel 版本, errata 版本
2. 什么文件系统,什么版本的
3. 什么存储，怎么连接的

另外，尽可能在TB级存储上避免单独mkfs一个超大分区然后直接mount上.我估计你不是用ext2就是ext3.如果TB级的ext2/3直接单独挂上去后，以后会有数不清的麻烦的. 从fsck开始到disaster recovery,从I/O blocking 开始到partition extending.

在生产环境下，正确的做法是:

1. upgrade你的linux kernel, errata到最新的, TB级存储，尽一切可能规避掉采用RedHat professional 之类的。RHEL, SLES是唯一的选择. FC也尽可能不要用.

2. 如果你的服务器是x86的，不是EM64T/AMD64的(x86_64)的，你就创建LVM分区,每个大小控制在400GB以内(当然，到底最小的用多少，要到现场采用一定的方法和手段作应用级的性能评估才能确定的，这里就是假设你是最普通的应用). 我习惯把所有的分区和lvm操作都脚本化. 所以我一般会切200G的LVM分区. 切多少个LVM partition,具体看你现在到底要用到多少, 比如你现在只要用1TB,就切5x200GB出来,剩下的不要理它.

3. 把你前面切出来的LVM Partition 用 pvcreate 做成PV,然后把用vgcreate  vgname pv1 pv2 pv3... 把你这些pv都放到一个新建的vg中去

4. vg做好后，vgscan一下，如果没有activated, vgchange -a y 来激活, 然后lvcreate从这个1TB的vg中切出你要得lv出来. 比如就是 1TB的lv

5. 给这个lv 创建文件系统，我建议你好好看清楚自己的应用 I/O行为到底是怎样的，如果是大块的顺序读，并且数据不需要太多的保护，直接用ext2是最优的选择，当然你linux玩的还过得去的话，我也建议你优先考虑xfs. 如果都是琐碎的不确定大小的文件，且随机读写操作频繁，建议用ReiserFS. 最后考虑ext3.  (n多人上来就用默认的ext3, ext3性能很糟糕，而且日志只有meta data才做，data区没有日志机制保护的，不像ReiserFS, JFS, XFS那样).

6. 以后要扩容了，就fdisk你的LUN,切出新的LVM partition, 然后用 pvcreate newpv1 newpv2 做好pv,然后用vgextend vgname newpv1 newpv2 newpv3把新的pv扩进去

7. 扩好了vg, 不用umount你之前的1TB LV的mountpoint,直接lvextend +LE numbers  oldLV 来热扩展你的LV,扩好了LV之后，用 reiserfs.resize或者ext3.resize或者xfs_resize之类的动态的热扩展你的mountpoint上的fs

8.瞬间就可以做好n个TB上的存储管理.

看着挺烦德对巴，其实linux下面很容易做,也就个10分钟的事情. 如果你的应用是生产环境的正规应用，忘掉你说的什么直接创建文件系统然后挂上去的做法把，这个是野路子的做法，基本上没有人在正规应用中这样操作TB级的linux存储管理的，主要的原因就是后患无穷。

作者: shtang 时间: 2005-12-13 01:28
2.4 kernel 要加patch不然有一個2T的上限 (對所有block device)

作者: nntp 时间: 2005-12-13 04:46

原帖由 shtang 于 2005-12-13 01:28 发表
2.4 kernel 要加patch不然有一個2T的上限 (對所有block device)

注意 2TB的限制，是说 filesystem ,不是说storage.两码事情.

lv出来后，创建fs的时候会有这个限制.

作者: foobar 时间: 2006-01-22 02:26

原帖由 nntp 于 2005-12-10 21:58 发表
n多人上来就用默认的ext3, ext3性能很糟糕，而且日志只有meta data才做，data区没有日志机制保护的，不像ReiserFS, JFS, XFS那样

ext3是可以保护data的一致性的，事实上用户可以选择三种不同的日志模式。我听说倒是JFS等系统不支持data journaling。

以下摘自：linux/Documentation/filesystems/ext3.txt

Data Mode
---------
There's 3 different data modes:

* writeback mode
In data=writeback mode, ext3 does not journal data at all.  This mode
provides a similar level of journaling as XFS, JFS, and ReiserFS in its
default mode - metadata journaling.  A crash+recovery can cause
incorrect data to appear in files which were written shortly before the
crash.  This mode will typically provide the best ext3 performance.

* ordered mode
In data=ordered mode, ext3 only officially journals metadata, but it
logically groups metadata and data blocks into a single unit called a
transaction.  When it's time to write the new metadata out to disk, the
associated data blocks are written first.  In general, this mode
perform slightly slower than writeback but significantly faster than
journal mode.

* journal mode
data=journal mode provides full data and metadata journaling.  All new
data is written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both
data and metadata into a consistent state.  This mode is the slowest
except when data needs to be read from and written to disk at the same
time where it outperform all others mode.

BTW, 请问有什么数据支持"ext3性能很糟糕"这样的说法？

[ 本帖最后由 foobar 于 2006-1-22 02:28 编辑 ]

作者: nntp 时间: 2006-01-22 21:13
道听途说，不如实际来做。opensource社区也有牛皮烘烘的东西.

ext3=烂.

作者: foobar 时间: 2006-01-22 21:45

原帖由 nntp 于 2006-1-22 21:13 发表
道听途说，不如实际来做。opensource社区也有牛皮烘烘的东西.

ext3=烂.

BTW, 请问有什么"实际"数据支持"ext3=烂"这样的说法？牛皮烘烘，不如给点实际东西。

作者: nntp 时间: 2006-01-23 12:54

原帖由 foobar 于 2006-1-22 21:45 发表

BTW, 请问有什么"实际"数据支持"ext3=烂"这样的说法？牛皮烘烘，不如给点实际东西。

具体项目中，具体谈，失败的案子我怎么会在这里公开说.

也许就是你用的某张银行卡的那个银行.

等我给实际的东西，不如自己去看去了解去比较，有什么能够比自己做出来的更加能说服自己呢?

[ 本帖最后由 nntp 于 2006-1-23 12:55 编辑 ]

作者: flanker_linux 时间: 2006-01-23 13:12
内核得打补丁，用parted分区。不要用fdisk分区。fdisk认不到>2T的分区
我做了一6T的分区，用XFS文件系统。
用ext3和reiserfs挂载的时候会有问题，用jfs，写完了卸载不了，而且管不了机。
最终用只能选择xfs了。

作者: bingosek 时间: 2006-01-23 13:36
请问nntp，你的扩建方法是流行和通用的，在多种存储和多种卷管理软件上扩展也都是这样做的，我的问题是扩建是容易的，缩小有没有比较稳当保险的方法？我一般为了保险缩小是做数据的导入导出的

作者: wolfop 时间: 2006-01-23 14:43

原帖由 foobar 于 2006-1-22 02:26 发表

ext3是可以保护data的一致性的，事实上用户可以选择三种不同的日志模式。我听说倒是JFS等系统不支持data journaling。

以下摘自：linux/Documentation/filesystems/ext3.txt

Data Mode
---------
The ...

谁在生产系统中用data 日志的？真晕，自己试试性能如何吧，那么怕丢的化，还不如对数据区分类型，需要保护的用rdbms。而且大家都是日志meta data的情况，ext3的性能也比jfs xfs差距很大。rhas3忘记u几之前的ext3还有严重BUG会让内核panic。
此外ext3在调整fs大小的时候必须umount，呵呵。

作者: foobar 时间: 2006-01-23 15:39

原帖由 wolfop 于 2006-1-23 14:43 发表

谁在生产系统中用data 日志的？真晕，自己试试性能如何吧，那么怕丢的化，还不如对数据区分类型，需要保护的用rdbms。而且大家都是日志meta data的情况，ext3的性能也比jfs xfs差距很大。rhas3忘记u几之前的ext3还有严重BUG会让内核panic。
此外ext3在调整fs大小的时候必须umount，呵呵。

只是说ext3可以支持data journaling (以回应bz的"ext3的data区没有日志机制保护的"的说法)，至于是不是适用于生产系统，那是另外的问题了。

“此外ext3在调整fs大小的时候必须umount”，这是老皇历了(RHEL4之前)。请先看看RHEL4中的ext2online命令。

至于ext3/jfs/xfs的性能比较，那恐怕是需要具体数据来说话了。至于那个严重BUG，如果方便的话最好也提供一些具体信息。实事求是嘛。

作者: q1208c 时间: 2006-01-24 02:50

原帖由 nntp 于 2005-12-13 04:46 发表

注意 2TB的限制，是说 filesystem ,不是说storage.两码事情.

lv出来后，创建fs的时候会有这个限制.

友情提示一下, storage 是 1T, 还不如 fs 呢.

作者: nntp 时间: 2006-01-24 13:05

原帖由 q1208c 于 2006-1-24 02:50 发表

友情提示一下, storage 是 1T, 还不如 fs 呢.

很奇怪么， HP MSA500, 14硬盘槽，核对目前的硬盘容量/价格比, 72GB的最好，14x72=1008GB 接近1T

1T的SCSI 集群存储是橄榄型的市场布局的当中的大头，做Linux的项目，80%的项目都聚集在 1T存储以内.

我只能说你的友情提示和现在的行业状况差距太远 :">

MSA1000(半光纤) EVA全光纤上，项目启动阶段(6个月-1年半左右)，数据规模保持在1T左右的也占据了大部分的项目百分比.

嘿嘿....

1T storage 不代表我要划1T的LUN出来，如果站在performance tuning的角度看待这个问题，cluster shared storage的性能优化思想中，最基本的一条就是striping, 所以即便你有1T以上的storage,也不会去划一个大LUN,然后直接创建fs. fs通常都是striping在不同的LV，而LV横跨了多个PV, PV则依赖于storage hardware的技术，跨在多个Lun上.

作者: bingosek 时间: 2006-01-24 13:09
我一般都用146的硬盘，73的容量不够大

作者: bingosek 时间: 2006-01-24 13:13
另外，“fs通常都是striping在不同的LV”这句话什么意思？
我一般是一个LV上建立一个文件系统，然后再mount上某个目录上的，这样做有问题吗？
我见到redhat在安装时使用lvm的话也是这样做的

作者: nntp 时间: 2006-01-24 20:14

原帖由 bingosek 于 2006-1-24 13:13 发表
另外，“fs通常都是striping在不同的LV”这句话什么意思？
我一般是一个LV上建立一个文件系统，然后再mount上某个目录上的，这样做有问题吗？
我见到redhat在安装时使用lvm的话也是这样做的

没有问题

作者: nntp 时间: 2006-01-24 20:15

原帖由 bingosek 于 2006-1-24 13:09 发表
我一般都用146的硬盘，73的容量不够大

中心思想是?

作者: q1208c 时间: 2006-01-24 23:15

原帖由 nntp 于 2006-1-24 13:05 发表

很奇怪么， HP MSA500, 14硬盘槽，核对目前的硬盘容量/价格比, 72GB的最好，14x72=1008GB 接近1T

1T的SCSI 集群存储是橄榄型的市场布局的当中的大头，做Linux的项目，80%的项目都聚集在 1T存储以内.
...

呵呵, 划多个 LUN就相当于多个 storage 了。　

作者: linvswin 时间: 2006-01-25 12:59
不能建超过2GB的文件怎么办

作者: nntp 时间: 2006-01-25 13:28

原帖由 q1208c 于 2006-1-24 23:15 发表

呵呵, 划多个 LUN就相当于多个 storage 了。　

HA 系统中,storage subsystem部分,我做LUN level 的protection, 司空见惯的方案.. 和多个storage就不是一个概念里面的东西了.

当然你说划分多个LUN相当于多个storage在只考虑存储的应用环境下是完全正确的,在HA环境下, No.

vmware的官方论坛涉及到很多基于vmware系统的(boot from SAN)的讨论,你可以参考学习一下.

[ 本帖最后由 nntp 于 2006-1-25 13:29 编辑 ]

作者: q1208c 时间: 2006-01-25 13:52

原帖由 nntp 于 2006-1-25 13:28 发表

HA 系统中,storage subsystem部分,我做LUN level 的protection, 司空见惯的方案.. 和多个storage就不是一个概念里面的东西了.

当然你说划分多个LUN相当于多个storage在只考虑存储的应用环境下是完全正确 ...

呵呵, SAN 的东东对我来说是太高深了, 因为没有环境, 看了也不明白.

作者: nntp 时间: 2006-01-25 15:44

原帖由 q1208c 于 2006-1-25 13:52 发表

呵呵, SAN 的东东对我来说是太高深了, 因为没有环境, 看了也不明白.

不复杂,入门的SAN 也就老三样, FC交换机, FC SAN storage(光纤的阵列柜), FC HBA卡和SAN管理软件

我工作的很多linux环境都是在SAN当中,也就这个样子了.

作者: q1208c 时间: 2006-01-26 18:36

原帖由 nntp 于 2006-1-25 15:44 发表

不复杂,入门的SAN 也就老三样, FC交换机, FC SAN storage(光纤的阵列柜), FC HBA卡和SAN管理软件

我工作的很多linux环境都是在SAN当中,也就这个样子了.

书我也看过, 简单的东西我也见过, 但因为没有实际用的机会, 所以, 最多只是个知道. 根本就不会用. 更不知道在实用中会有什么情况.

作者: nntp 时间: 2006-01-27 13:56

原帖由 q1208c 于 2006-1-26 18:36 发表

书我也看过, 简单的东西我也见过, 但因为没有实际用的机会, 所以, 最多只是个知道. 根本就不会用. 更不知道在实用中会有什么情况.

给你也给大家一个建议.

工作学习中，我们如非机缘巧合，很难接触到完整的全系列的设备和系统，软件还好说，硬件的东西就不可能随便找到了，但是谢天谢地，我们有很多的途径可以不用站在设备旁边就可以完全清楚地了解它.

1. live drive, IBM和HP都有 online live drive,直接给你ssh，远程过去使用绝大部分的厂商的设备，费用都是free.

2. ProductSpec,  产品的规格书，规格书有产品和方案的详细的连接结构，外部内部图，每个端口的定义等等。

3. Best Practices  最佳实践的文档，描述的是非常详细的一次安装/部署/调优的过程，阅读完毕基本上上就是带你走了一遍.

4. Simulator  很多设备厂商都提供了simulator.

也许实物旁你可以学习的更快，但是不是每个人都有机会去接触几十万几百万的设备的，但是我们的信息渠道并不闭塞，完全可以通过这些手段获得一样的学习效果.

即便是我们这样的工作环境，自己公司的设备也不是都能全部接触到，更不要说是竞争对手的了，但是这个根本不成为我去了解熟悉甚至精通他们的阻碍，唯一的阻碍就是我自己偷懒不想去花这些时间.

[ 本帖最后由 nntp 于 2006-1-27 13:59 编辑 ]

作者: q1208c 时间: 2006-01-27 14:25

原帖由 nntp 于 2006-1-27 13:56 发表

给你也给大家一个建议.

工作学习中，我们如非机缘巧合，很难接触到完整的全系列的设备和系统，软件还好说，硬件的东西就不可能随便找到了，但是谢天谢地，我们有很多的途径可以不用站在设备旁边就可以完 ...

谢谢提示. 我会试试的.

当然, 今后的一段时间, 可能我会有更多的精力在这方面的.

作者: suran007 时间: 2006-02-10 17:35
请问版主，网上有没有磁盘柜的的虚拟机，类似cisco的虚拟机simulator，可以供初学者练练手，还有就是版主提到的IBM和HP的live drive,能不能提供个连接地址？谢谢了先~

作者: nntp 时间: 2006-02-11 00:50

原帖由 suran007 于 2006-2-10 17:35 发表
请问版主，网上有没有磁盘柜的的虚拟机，类似cisco的虚拟机simulator，可以供初学者练练手，还有就是版主提到的IBM和HP的live drive,能不能提供个连接地址？谢谢了先~

柜子的simulator ,我没有看到过，我看到过Netapp filer的simultor.

HP: www.testdrive.hp.com

IBM:https://www.developer.ibm.com/is ... 0&source=ilinux

Intel:http://www.intel.com/cd/ids/developer/asmo-na/eng/99144.htm

干吗不自己在 hp, ibm的站点的search 框内输入 testdrive呢? 搞不懂.

作者: initx 时间: 2006-02-17 17:52
提示: 作者被禁止或删除内容自动屏蔽

作者: erjing 时间: 2006-06-29 22:12
简单描述一下如何使用大于2TB的文件系统。
大家可能都和我一样遇到过如此问题，看到上面很多兄弟在争论，我也来说说看法。
就我的理解：
如果想在X86里面使用大于2TB的分区，是可以的，但是前提条件是使用安藤Itanium芯片的机器，在linux下用parted可以分出来大于2TB的分区，但是前提条件也是使用安藤芯片，简单理解就是64的芯片。在parted下标记出来GPT的label（也就是GUID的分区表，和MBR可不兼容，M$的一些产品，比如集群就不支持在GPT的分区中使用，所以在64位的机器中一定要小心了。）然后再分区。这样就支持很大很大的分区了。
如果你的机器不是64位的，那也没有问题，大家都知道目前文件系统早就突破了2TB的界限，所以，我们在32位的机器（比如Xeon基于IA32的）中，只需要使用lvm2就行了。lvm2支持在32位的系统下大于2TB的分区，它相当于在pci总线和文件系统中间了一个虚拟的层。这样就很容易的突破了2TB的分区。
对了，你要确定你的SCSI卡是64位的，否则即便你的disk array是>2TB的，你的机器还是认不出来，不过一般来说，现在的服务器都是64位的pci卡了，比如dell 1850 ,2850。
总结一下，想使用大于2TB的文件系统在linux下有2种方法：
1、使用64位的系统，比如安藤系统。然后在linux下用parted建立GPT的分区表（不是msdos[MBR]或者loop），然后建立超级大的分区，然后直接用XFS（我比较喜欢这个）format就行了。
2、使用32位的系统，比如Xeon，在linux下建立N个分区，然后用LVM2来做虚拟盘，比如20个400G的盘，算算看就知道是8TB。
这里还有一些归纳：
１、对于GUID分区表（GPT）磁盘，最多可创建128个主磁盘分区。
２、x86 使用msdos，Itanium 使用gpt。
３、Redhat要到As4，而且是pack1之后才支持，如果仅仅是as4，需要打补丁。当然如果大家用centos很方便了。
４、图省力，把/dev/sda直接格式化为一个分区，是绝对绝对不推荐的。大家一定要记主！绝对不要直接把块设备格式化了。至少也要有个sda1。

　http://wuarchive.wustl.edu/pub/c ... NOTES-U1-zh_CN.html　这里讲了为啥要用安藤。
http://www.adaptec.com/pdfs/3759_2TB_WP.pdf
这里讲了2TB的方案，从历史原因到现状。除了linux的还有如何在M$下使用大于2TB的磁盘。很详细的，建议初级作存储的兄弟都可以看看。

大概抄录一下：
Commonly, the firmware, BIOS, driver, and at least part of the
storage stack support 32-bit block numbers, thereby limiting
the storage to 2TB. However since most filesystems support
page sizes larger than 512 B, they actually already support volumes
greater than 2TB. In other words, a filesystem may have
only 32-bit block numbers, but those blocks are commonly
multiples of 512 bytes, such as 2KB, 4KB, 8KB, etc., allowing
the volume size to be 8TB, 16TB, 32TB, respectively. Of
course, the factors that go into defining the max volume size
are much more complicated than this, but block size certainly
is an important factor.
With drivers presenting up to 2TB volumes and filesystems
supporting greater than 2TB volumes, there is one piece of the
puzzle missing: a method for combining smaller drive volumes
into larger filesystem volumes. This is possible with the several
operating systems (OS) that have a virtualization layer in the
storage stack. Just like the array virtualization in a PCI RAID
controller, the OS virtualization layer is able to combine smaller
volumes (disks) into a larger volume (virtual disk) for
improved performance and increased capacity. This low-overhead,
high-performance operating system layer is the key to
the solution presented in this paper.

BTW:我随手写的哦，没有好好组织语言，大家凑或看看吧。CU的朋友也可以直接联系我:MSN
Erjing (at) hotmail.com，我有空的时候乐意帮大家解决问题。我不是做存储的，太专业的问题俺就

[ 本帖最后由 erjing 于 2006-6-29 23:43 编辑 ]

作者: erjing 时间: 2006-06-29 22:57

原帖由 erjing 于 2006-6-29 22:12 发表
简单描述一下如何使用大于2TB的文件系统。
大家可能都和我一样遇到过如此问题，看到上面很多兄弟在争论，我也来说说看法。
就我的理解：
如果想在X86里面使用大于2TB的分区，是可以的，但是前提条件是使用安藤 ...

加一句，如果想使用LVM，用fdisk是不能给大于2TB的设备分区的，还是要用parted.
而且要gpt,就像这样：
mkpart  primary ext2 0 200000
mkpart  primary ext2 200001 400000
mkpart  primary ext2 400001 600000
mkpart  primary ext2 600001 800000
mkpart  primary ext2 800001 1000000
mkpart  primary ext2 1000001 1200000
mkpart  primary ext2 1200001 1400000
mkpart  primary ext2 1400001 1600000
mkpart  primary ext2 1600001 1800000
mkpart  primary ext2 1800001 2000000
mkpart  primary ext2 2000001 2200000
mkpart  primary ext2 2200001 2400000
mkpart  primary ext2 2400001 2600000
mkpart  primary ext2 2600001 2800000
mkpart  primary ext2 2800001 3000000
如果你用
mkpart  extended  0 3000000
mkpart  logical ext2 0 200000
mkpart  logical ext2 200001 400000
mkpart  logical ext2 400001 600000
mkpart  logical ext2 600001 800000
mkpart  logical ext2 800001 1000000
mkpart  logical ext2 1000001 1200000
mkpart  logical ext2 1200001 1400000
mkpart  logical ext2 1400001 1600000
mkpart  logical ext2 1600001 1800000
mkpart  logical ext2 1800001 2000000
mkpart  logical ext2 2000001 2200000
mkpart  logical ext2 2200001 2400000
mkpart  logical ext2 2400001 2600000
mkpart  logical ext2 2600001 2800000
mkpart  logical ext2 2800001 3000000
会发生什么？最多到1T就分不下去了。
如果你用fdisk -l会看到什么？
Device Boot    Start       End    Blocks Id  System
/dev/sda1             1    267350  2147483647+  ee  EFI GPT
是的，看不到你的分区，所以一定要养成用parted来看分区的习惯，忘记fdisk吧。

看看这里：
ls /dev/sda* -l
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda1
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda10
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda11
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda12
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda13
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda14
brw-rw----  1 root disk 8,  XXXXXXXXXXXX/dev/sda15
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda2
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda3
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda4
brw-rw----  1 root disk 8,  XXXXXXXXXXXX/dev/sda5
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda6
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda7
brw-rw----  1 root disk 8,  XXXXXXXXXXXX /dev/sda8
brw-rw----  1 root disk 8,  XXXXXXXXXXXX/ dev/sda9
这才是你想要的。

[ 本帖最后由 erjing 于 2006-6-29 23:10 编辑 ]

作者: likuku 时间: 2006-07-01 17:09
同意楼上的！！

FS和分区是两个概念.

当然,如此大的分区,最好使用SGI开发的64位XFS文件系统.

传统的基于MBR的分区(分区表由MBR记录),分区大小在当前巨大容量存储器面前已经不够用.

32位的MBR 只支持到2TB分区,64位的GPT支持比他大多了。

你得换用GPT分区,GPT支持极大分区.

Linux 下的 parted 支持进行GPT分区.

我没用过GPT,我有朋友在FreeBSD 下成功用过GPT,他也是因为3TB大小设备的问题..

google 搜到的 debian 安装手册提到的 ia64 上的GPT分区过程

http://www.debian.org/releases/stable/ia64/apbs05.html.zh_CN

B.5.1. 为 IA-64 准备分区

partman 是安装程序的缺省分区工具。它管理一系列分区以及挂载点，来保证磁盘和文件系统对于成功的安装来说具有有合适的配置。实际上它使用的是 parted 来进行磁盘分区的。
EFI 能够识别的格式

IA64 EFI 固件支持 GPT 和 MS-DOS 两种分区表(或者磁盘标记)格式。MS-DOS 格式通常用在 i386 PC 上，并且对于 IA64 系统来说并不合适推荐使用。尽管安装程序同时提供了 cfdisk，您应该只采用 parted，因为只有它能够同时正确地管理 GPT 和 MS-DOS 分区表。

partman 自动分区方案会分配一个 EFI 分区作为磁盘上的第一个分区。您也可以在主菜单下选择 Guided partitioning 配置分区。其方法类似设置一个交换分区。

partman 分区工具将掌握大部分的磁盘布局。对于那些需要手工设置磁盘的罕见例子，您可以按照上面方法采用 shell 并且直接运行 parted 工具下的明令行界面。比如您想擦除您的整个硬盘并且创立一个 GPT 分区表以及一些分区，则可以才采用类似下面命令的方法：

   mklabel gpt
   mkpartfs primary fat 0 50
   mkpartfs primary linux-swap 51 1000
   mkpartfs primary ext2 1001 3000
   set 1 boot on
   print
   quit

这里创建了一个新的分区表，以及三个分区分别用做 EFI 引导分区，交换空间以及一个根文件系统。最后它设置了 EFI 分区的引导标记。分区将用兆字节，以及起始和结束位置到磁盘开始的偏移量来表示。因此，比如在上面我们在到磁盘开始处偏移量为 1001MB 的地方开始创建了一个 1999MB ext2 文件系统。注意采用 parted 格式化交换分区，可能要花一些时间来完成，因为它可能要扫描坏区。
B.5.2. 启动引导器分区要求

ELILO 作为一种 ia64 启动引导器需要一个含有 FAT 文件系统的分区。且此分区标记为 boot。分区必须足够大以便能够放入启动引导器，您想引导的内核以及 RAMdisks 内存磁盘镜像。最小的尺寸大概有 20MB，但是如果您想使用多个内核的话，128MB 也许更好。

因为 EFI Boot Manager 以及 EFI Shell 完全支持 GPT 表格所以引导分区不需要一定是第一个分区，甚至可以不在本地磁盘上。这样方便您在格式化磁盘上的其它分区后再决定。partman 分区程序将在设置 root 分区时会同时检查一个 EFI 分区。这样您就有机会在开始安装软件包之前检查磁盘的布局。纠正这个问题的最简单的方法，是在最后一个分区末尾留下足够的磁盘空间，来加入一个 EFI 分区。

强烈建议您把 EFI 引导分区和 root 文件系统分配在同一个磁盘上。
B.5.3. EFI 诊断分区

对于在大多数 x86 PCs 上常见的 BIOS 来说，EFI 固件明显要复杂的多。一些系统制造商利用 EFI 的优点从硬盘文件系统来访问文件以及运行程序以保存一些诊断信息和 EFI 的系统管理工具。这将在系统磁盘上存在一个分开的 FAT 文件系统。请查阅随机相关的系统文档和附件以获得细节。最轻松设置一个诊断分区的时候是在设置 EFI 引导分区的时候

关于GPT
我们freebsdchina 的大牛 dephij 给出的建议：

原文由 dephij 撰写

gpt在x86上相当稳定。

不过我们的实际经验，这样大的FS （超过1TB）在盘阵出现磁盘物理损坏时的抗毁能力不很强。如果你的系统运行下列应用之一：
- 海量下载服务
- 繁忙的邮件服务

(特征是：读写操作量基本一样多，并且主要是随机访问)

则应使用gpt，或在gpt基础上用bsdlabel来划分label，分成500G以下的分区，这意味着在出现问题的时候能够迅速恢复。

关于"在gpt基础上用bsdlabel来划分label，分成500G以下的分区" ，你在linux,可以用 "在gpt基础上划成一个扩展分区，在扩展分区上分若干个逻辑分区"来代替，假如扩展分区能用 GPT的话(具体请自行查询/试验)。

给你篇使用FreeBSD 的上海朋友使用GPT的例子(文尾给出的3个帖子链接，一定要看):
http://www.freebsdchina.org/forum/viewtopic.php?t=28415

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)