求助..谁知道在linux下怎么挂上3tb的外设.

nntp

怎么会?

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

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存储管理的，主要的原因就是后患无穷。

nntp

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

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

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

nntp

道听途说，不如实际来做。opensource社区也有牛皮烘烘的东西.

ext3=烂.

nntp

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



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

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

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

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

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

nntp

原帖由 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上.

nntp

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

没有问题

nntp

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

中心思想是?

nntp

原帖由 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 编辑 ]

nntp

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

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

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

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

nntp

原帖由 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 编辑 ]