eygle.com   eygle.com
eygle.com eygle
eygle.com  
 
Digest Net: March 2012 Archives

March 2012 Archives

作为全球最大的科技公司之一,甲骨文的经历与苹果十分相似:都曾经历巨额亏损的低潮,也都创造了逆境翻身的奇迹,都拥有自己的灵魂领袖,也都在"狂人"的推动下开疆拓土。如今的甲骨文,在巩固软件业龙头地位的同时不断大举收购,正朝着打造全能型高科技航母的方向迈进。

兴衰三十年

1977 年,拉里·埃里森连同鲍勃·迈纳和爱德华·奥茨,筹资2000美元在硅谷创办了一家软件开发试验室(SDL),为客户提供独立软件开发服务。随后SDL获 得美国中情局投资的一个名为"Oracle"的项目,赚了第一桶金。不久后SDL便更名为"Oracle",取"神谕,预言"之意,中文译名甲骨文。

1986 年3月12日,甲骨文公司公开上市,首日股价涨幅就达到28%,市值当天便达到2.7亿美元。上市之后,甲骨文开始更快地聚积财富。当时埃里森曾提出一个 目标,就是公司每年销售额都要翻一番。事实上自1986年开始,甲骨文每年的销售额增幅都超过100%,到1990年已经达到9.75亿美元。

然 而急剧扩张的背后也充满了隐患。在甲骨文鼓励销售政策的怂恿下,许多销售员在对方无法付款的情况下就将销售额入账,甚至与买方达成私下协议并进行贿赂。这 使得甲骨文的财务数据中暗藏着数不清的坏账。最终这块高悬已久的巨石坍塌,甲骨文在1991财年首次曝出1200万美元的亏损。受此影响,公司股价也从 30美元附近跌落至5美元。

为了挽救陷入困境的甲骨文,埃里森临危受命担当起公司首席执行官。在裁员、减少开支以及研发新产品等一系列措施 推动之下,甲骨文扭转颓势,在第二年就重新实现盈利。如今的甲骨文,年收入已经达到360亿美元,净利润达到85亿美元,市值高达1500亿美元,成为全 球最大的企业软件产品提供商。

收购狂人软硬兼吃

如同乔布斯之于苹果、比尔·盖茨之于微软一样,拉里·埃里森堪称甲骨文的灵魂领袖。在他的领导下,甲骨文从硅谷一家小试验室起步,跃身成为行业领头羊。而为了顺应时代潮流,埃里森还推动甲骨文在实现产品多元化发展之外,通过并购实现转型。

在 硅谷,埃里森绝对算得上一个收购狂人。自2005年以来,甲骨文累计斥资近400亿美元收购了50多家公司。其中包括2005年以103亿美元的价格收购 企业管理软件三巨头之一的仁科公司,2008年以85亿美元的大手笔"强娶"了全球中间件软件老大BEA公司。而后者使甲骨文的全球竞争对手直接从单纯的 管理软件巨头SAP转向IBM等综合解决方案供应商。

在一系列纵深式的行业整合后,甲骨文在2009年开始了横向的跨界扩张,斥资74亿美 元收购IT服务提供商Sun公司。在埃里森看来,这宗交易意味着一家一流的软件公司与一家高端计算机公司实现了完美的结合,将在一定程度上改变IT业的格 局。完成这桩收购后,甲骨文已然成为软硬兼备的企业,进而向全面的IT解决方案提供商转型。

如今甲骨文的产品与服务已经覆盖了整个IT生命 周期,包括底层操作系统、数据库、中间件、企业应用以及咨询服务等。在财富500强企业中,有98%的企业都在应用甲骨文的技术产品,几乎覆盖了世界上所 有的行业。与此同时,甲骨文也在推进软硬融合的整体化解决方案,规划着全能型IT服务商的蓝图。

85倍高回报

在实现自身飞跃式发展的同时,甲骨文也给投资者带来丰厚回报。据《财智月刊》统计,自1992年4月以来甲骨文公司的总回报率高达8571%,在过去二十年十大牛股的榜单上位居第六位。

在2000年市场最为火爆的时期,甲骨文股价曾达到每股90美元,但互联网泡沫破灭后不到一年就跌至10美元附近。在市场恢复平静后,甲骨文股价开始稳步攀升,目前股价在30美元附近。统计显示,目前甲骨文市盈率15倍,相比之下纳斯达克指数平均市盈率为24倍。

本 月21日甲骨文公布的最新财报显示,截至2012年2月29日第三财季公司实现总营收90亿美元,同比增长3%;实现净利润25亿美元,同比增长18%。 公司首席财务官萨夫拉·卡茨表示,作为一家综合性的硬件和软件公司,甲骨文关注于高利润的软硬件匹配设计的系统,因此有能力实现创纪录的利润率。

第三财季,甲骨文新软件授权营收为24亿美元,同比增长7%,位于甲骨文自己预测区间的上端。对于投资者而言,新软件授权营收是预测甲骨文未来盈利表现的重要指标,因为这项业务不但利润高,而且带来长期维护的合同。

财报公布后,甲骨文股价跃升至三个月以来高点,与上一次财报公布后股票遭到抛售形成鲜明对比。此前由于甲骨文公布的第二财季盈利十年来首次不及预期,导致公司股票大跌8%。

对 于当前财季表现,甲骨文预计本财季的盈利可能会继续超出预期,埃里森还表示下一财年甲骨文的硬件业务收入也将实现增长。洛杉矶资产管理公司RNC詹特尔公 司首席投资官丹尼尔·詹特尔表示,第三财季对甲骨文来说是一个非常重大的转机,"唯一不足的地方就是硬件收入有点低"。

(本文来源:中国证券报 作者:杨博)

中新网2012年3月19日电 据华尔街日报中文网消息,《财智月刊》找出过去20年里表现最好的10只股票,产生的总回报率高达9,839%。苹果公司以其3,000%左右的回报率没能成功跻身这十强,不过这十强股票中,的确有两家公司与iPhone手机有关。


20年间,股票市场经历过不少动荡起伏,见证了谷歌的上市、网络公司Pets.com的一败涂地、雷曼兄弟的破产、以及苹果公司成为全球最大企业的成功。

《财智月刊》为了找出过去20年里表现最好的10只股票,把搜索对象限定为1992年4月时被罗素3000指数(Russell 3000)涵盖在内的上市公司。这个指数追踪美国最大的3000家上市公司股票。其成份股中包括大量小型股,不过其涵盖的总市值相当于美国可投资市场的 98%。接下来要做的事情是在这里面搜索过去20年里投资回报率最高的股票。

如果投资者在1992年4月时买入一只指数基金,在经历这些年的动荡起伏后,持有该基金也能获得不错的回报:标准普尔500指数(S&P 500)这些年的回报率是382%,也就是说,若独青睐指数投资,那么投资者如今手中的财富已是当年的四倍了。

不过,这十佳股票在过去20年里产生的总回报率则要高达9,839%。换言之,如果你在1992年4月用1,000美元来投资标准普 尔500指数基金,那么今天这份投资的价值将是3,820美元,但如果这1,000美元用来买下文列出的这10只股票,那么你的投资组合如今的价值将是 98,393美元。

若要获得9,000%的回报,投资者还需在其中几只股票出现大幅下挫时经得住考验。这里面有几只股票在互联网泡沫时期跌势惨重,而且迄今也没有完全恢复元气──不过持有这些股票仍能够让投资者手中的财富在这些年后,变成当初的80倍、甚至90倍。

苹果公司以其3,000%左右的回报率没能成功跻身这十强,不过这十强股票中,的确有两家公司与iPhone手机有关。下面就是这十强股票:

  第十位:Astronics

自1992年4月以来的总回报率:6,004%

该公司是一家商用航天设备供应商,生产的产品包括安装在飞机座椅背面的电视屏幕、以及让乘客在搭乘飞机时能够给随身带的小电器充电的电源插座。该股股价在2007年达到峰值,当时报价接近每股50美元;目前该股价格不到33美元。


  第九位:Celgene Corporation

自1992年4月以来的总回报率:6,244%

这是一家生物科技公司,其成功大多要归功于该公司所生产的用于治疗多发性骨髓瘤的药物。多发性骨髓瘤是血癌的一种。在Piper Jaffray研究生物科技行业的分析师伊恩•索麦亚(Ian Somaiya)说,"这一直以来都是一家很棒的公司,其生产的药物也很棒。"据索麦亚称,他向投资者推荐买入这只股票已经有15年的时间了。索麦亚表 示,该公司旗下用于治疗血癌的药物包括沙利度胺(Thalomid, 又名thalidomide)和来那度胺(Revlimid),这两种药物都将多发性骨髓瘤患者的寿命大大延长了,其中,来那度胺是沙利度胺的仿制药,前 者比后者的副作用更小。

第八位:百健艾迪公司(Biogen Idec)

自1992年4月以来的总回报率:6,334%

这家生物科技公司的增长轨迹并不像Celgene那样平稳,不过该股股价自2010年以来增长了一倍。该公司最知名的产品是用于治疗多发性硬化症的 药物阿沃纳斯(Avonex)以及之后开发出的药品那他珠单抗注射液(Tysabri)。Piper Jaffray的索麦亚表示,该股近年来大幅上涨主要是由于,该公司所开发新药的临床结果要好于预期。这种新药是片剂(不像之前的药品那样是注射液),也 用于治疗多发性硬化症。

  第七位:Diodes

自1992年4月以来的总回报率:8,601%

这家公司在20年前只是一家半导体产品分销商。据Benchmark Company的资深分析师加里•莫布利(Gary Mobley)介绍,到上世纪90年代末,Diodes成为一家名为建兴电子(Lite-On)的台湾制造商在美国的独家代理,之后该公司利用从独家代理 业务中获得的现金流将业务扩大,成为一家自行生产半导体设备的制造商。

  第六位:甲骨文公司(Oracle)


自1992年4月以来的总回报率:8,571%

晨星公司一位分析师曾在2000年3月时写道,"尽管长期以来甲骨文公司在企业软件市场中的地位无人能敌,但其股价所反映的市场情绪已经太过乐观 了。"此言不虚,该公司股价在2000年达到峰值,升至每股45美元左右。在互联网泡沫破灭后,该股实现了稳步复苏,不过以当前接近每股30美元的价格, 甲骨文还没有完全恢复昔日风采。

  第五位:高通公司(Qualcomm)

自1992年4月以来的总回报率:9,232%

这家芯片制造商股价也在2000年达到峰值,当时每股报价约75美元,随后暴跌后一路回攀至如今每股62美元的水平。Sterne, Agee & Leach的股票分析师维贾伊•拉克什(Vijay Rakesh)说,"高通公司表现一直十分出色。"该公司开发出的码分多址技术(code division multiple access, 简称CDMA)成为无线网络的一项重要技术。该公司拥有多项与此技术有关的专利,这使得它能够向几乎所有移动电话硬件制造商收取专利授权费。该公司还为包括iPhone在内的许多移动电话提供芯片,其芯片产品制作工艺更为复杂,因此高通能够获得比诸如Diodes这样的公司更高的利润率。

  第四位:EMC公司

自1992年4月以来的总回报率:9,624%

这是又一家在互联网泡沫破灭时遭受沉重打击的公司,2000年时,EMC股价是当前每股28美元这一价格的三倍多。不过一直以来,这家数据存储公司在这个瞬息万变的行业中成功保持住了自己的竞争优势。

  第三位:贰陆公司(II-VI)


自1992年4月以来的总回报率:10,423%

贰陆公司创业之初只生产一种激光光学元件。据Longbow Research的资深股票分析师马克•道格拉斯(Mark Douglass)称,这种元件就像剃须刀片一样──是整台设备的关键部位,而且需要定期更换。道格拉斯表示,自上世纪90年代以来,激光设备在工业生产 领域的应用出现激增,其增长速度比GDP的增速要快好几倍,因此"这家公司基本上是搭上了顺风车。"他称,贰陆公司在业内声望也很高,基本上占据了市场的 半壁江山,而且历来利润率都很高。

 第二位:Middleby

自1992年4月以来的总回报率:14,330%

这家厨房用品制造商股价的增长大多是在过去10年中完成的。该公司生产烤箱以及其他供饭店使用的厨具,"不过该公司大概更像是一家科技企业,而非工 业企业或是设备制造商,"罗仕证券(Roth Capital Partners)的证券分析师安东•布伦纳(Anton Brenner)表示。他指出,"该公司是行业里最具创新力的企业。"

 第一位:Kansas City Southern


自1992年4月以来的总回报率:19,030%

除了在2008年和2009年跟随市场整体走低外,该股自上世纪90年代末以来一直在稳步攀升。不过当年这家公司看起来有些不同。晨 星的莱森说,"当时这是一家综合性企业,而且是一家很奇怪的综合企业。它同时具有铁路业务和资产管理业务。"该公司的资产管理业务于2000年被独立拆分 出去,成为如今的上市公司Janus Capital Group。莱森表示,"在当年拆分时,该公司最具价值的业务是这个资产管理公司,而非铁路。"不过自独立至今,Janus的股价已经跌去78%,而 Kansas City Southern的股价却上升了1,051%。当初Kansas City Southern的利润率要低于行业平均水平,不过该公司的铁道一直延伸到墨西哥境内,因此在"北美自由贸易协议"(NAFTA)带动下日渐活跃的跨境贸 易令这家公司大为受益。如今其利润率已经接近行业均值。显然这个乌鸦变凤凰的故事已经让耐心的投资者得到了回报,不过晨星的分析师们相信,该公司最风光的 日子还在后头。(中新网证券频道)


原文地址:http://www.mike.org.cn/articles/linux-xiangjie-udev/

如果你使用Linux比较长时间了,那你就知道,在对待设备文件这块,Linux改变了几次策略。在Linux早期,设备文件仅仅是是一些带有适当 的属性集的普通文件,它由mknod命令创建,文件存放在/dev目录下。后来,采用了devfs, 一个基于内核的动态设备文件系统,他首次出现在2.3.46内核中。Mandrake,Gentoo等Linux分发版本采用了这种方式。devfs创建 的设备文件是动态的。但是devfs有一些严重的限制,从2.6.13版本后移走了。目前取代他的便是文本要提到的udev--一个用户空间程序。

目前很多的Linux分发版本采纳了udev的方式,因为它在Linux设备访问,特别是那些对设备有极端需求的站点(比如需要控制上千个硬盘)和热插拔设备(比如USB摄像头和MP3播放器)上解决了几个问题。下面我我们来看看如何管理udev设备。

实际上,对于那些为磁盘,终端设备等准备的标准配置文件而言,你不需要修改什么。但是,你需要了解udev配置来使用新的或者外来设备,如果不修改 配置, 这些设备可能无法访问,或者说Linux可能会采用不恰当的名字,属组或权限来创建这些设备文件。你可能也想知道如何修改RS-232串口,音频设备等文 件的属组或者权限。这点在实际的Linux实施中是会遇到的。

为什么使用udev

在此之前的设备文件管理方法(静态文件和devfs)有几个缺点:

*不确定的设备映射。特别是那些动态设备,比如USB设备,设备文件到实际设备的映射并不可靠和确定。举一个例子:如果你有两个USB打印机。一个 可能称 为/dev/usb/lp0,另外一个便是/dev/usb/lp1。但是到底哪个是哪个并不清楚,lp0,lp1和实际的设备没有一一对应的关系,因为 他可能因为发现设备的顺序,打印机本身关闭等原因而导致这种映射并不确定。理想的方式应该是:两个打印机应该采用基于他们的序列号或者其他标识信息的唯一 设备文件来映射。但是静态文件和devfs都无法做到这点。

*没有足够的主/辅设备号。我们知道,每一个设备文件是有两个8位的数字:一个是主设备号 ,另外一个是辅设备号来分配的。这两个8位的数字加上设备类型(块设备或者字符设备)来唯一标识一个设备。不幸的是,关联这些身边的的数字并不足够。

*/dev目录下文件太多。一个系统采用静态设备文件关联的方式,那么这个目录下的文件必然是足够多。而同时你又不知道在你的系统上到底有那些设备文件是激活的。

*命名不够灵活。尽管devfs解决了以前的一些问题,但是它自身又带来了一些问题。其中一个就是命名不够灵活;你别想非常简单的就能修改设备文件的名字。缺省的devfs命令机制本身也很奇怪,他需要修改大量的配置文件和程序。

*内核内存使用,devfs特有的另外一个问题是,作为内核驱动模块,devfs需要消耗大量的内存,特别当系统上有大量的设备时(比如上面我们提到的系统一个上有好几千磁盘时)

udev的目标是想解决上面提到的这些问题,他通采用用户空间(user-space)工具来管理/dev/目录树,他和文件系统分开。知道如何改变缺省配置能让你之大如何定制自己的系统,比如创建设备字符连接,改变设备文件属组,权限等。

udev配置文件

主要的udev配置文件是/etc/udev/udev.conf。这个文件通常很短,他可能只是包含几行#开头的注释,然后有几行选项:

udev_root="/dev/"
udev_rules="/etc/udev/rules.d/"
udev_log="err"

上面的第二行非常重要,因为他表示udev规则存储的目录,这个目录存储的是以.rules结束的文件。每一个文件处理一系列规则来帮助udev分配名字给设备文件以保证能被内核识别。
你的/etc/udev/rules.d下面可能有好几个udev规则文件,这些文件一部分是udev包安装的,另外一部分则是可能是别的硬件或者软件包 生成的。比如在Fedora Core 5系统上,sane-backends包就会安装60-libsane.rules文件,另外initscripts包会安装60-net.rules文 件。这些规则文件的文件名通常是两个数字开头,它表示系统应用该规则的顺序。

规则文件里的规则有一系列的键/值对组成,键/值对之间用逗号(,)分割。每一个键或者是用户匹配键,或者是一个赋值键。匹配键确定规则是否被应 用,而赋 值键表示分配某值给该键。这些值将影响udev创建的设备文件。赋值键可以处理一个多值列表。匹配键和赋值键操作符解释见下表:

udev 键/值对操作符

操作符        匹配或赋值                             解释
----------------------------------------
==             匹配                        相等比较
!=              匹配                        不等比较
=                赋值                       分配一个特定的值给该键,他可以覆盖之前的赋值。
+=              赋值                       追加特定的值给已经存在的键
:=               赋值                       分配一个特定的值给该键,后面的规则不可能覆盖它。

这有点类似我们常见的编程语言,比如C语言。只是这里的键一次可以处理多个值。有一些键在udev规则文件里经常出现,这些键的值可以使用通配符(*,?,甚至范围,比如[0-9]),这些常用键列举如下:

常用udev键
键                 含义
ACTION                     一个时间活动的名字,比如add,当设备增加的时候
KERNEL                     在内核里看到的设备名字,比如sd*表示任意SCSI磁盘设备
DEVPATH              内核设备录进,比如/devices/*
SUBSYSTEM              子系统名字,比如sound,net
BUS                     总线的名字,比如IDE,USB
DRIVER                     设备驱动的名字,比如ide-cdrom
ID                       独立于内核名字的设备名字
SYSFS{ value}              sysfs属性值,他可以表示任意
ENV{ key}              环境变量,可以表示任意
PROGRAM              可执行的外部程序,如果程序返回0值,该键则认为为真(true)
RESULT                     上一个PROGRAM调用返回的标准输出。
NAME                     根据这个规则创建的设备文件的文件名。注意:仅仅第一行的NAME描述是有效的,后面的均忽略。 如果你想使用使用两个以上的名字来访问一个设备的话,可以考虑SYMLINK键。
SYMLINK              根据规则创建的字符连接名
OWNER                     设备文件的属组
GROUP                     设备文件所在的组。
MODE                     设备文件的权限,采用8进制
RUN                     为设备而执行的程序列表
LABEL                     在配置文件里为内部控制而采用的名字标签(下下面的GOTO服务)
GOTO                     跳到匹配的规则(通过LABEL来标识),有点类似程序语言中的GOTO
IMPORT{ type}           导入一个文件或者一个程序执行后而生成的规则集到当前文件
WAIT_FOR_SYSFS         等待一个特定的设备文件的创建。主要是用作时序和依赖问题。
PTIONS                     特定的选项: last_rule 对这类设备终端规则执行; ignore_device 忽略当前规则; ignore_remove 忽略接下来的并移走请求。all_partitions 为所有的磁盘分区创建设备文件。

我们给出一个列子来解释如何使用这些键。下面的例子来自Fedora Core 5系统的标准配置文件。

KERNEL=="*", OWNER="root" GROUP="root", MODE="0600" 
KERNEL=="tty", NAME="%k", GROUP="tty", MODE="0666", OPTIONS="last_rule"
KERNEL=="scd[0-9]*", SYMLINK+="cdrom cdrom-%k"
KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1",
               SYSFS{device/media}=="cdrom", SYMLINK+="cdrom cdrom-%k" 
ACTION=="add", SUBSYSTEM=="scsi_device", RUN+="/sbin/modprobe sg"

上面的例子给出了5个规则,每一个都是KERNEL或者ACTION键开头:

*第一个规则是缺省的,他匹配任意被内核识别到的设备,然后设定这些设备的属组是root,组是root,访问权限模式是0600(-rw-----)。这也是一个安全的缺省设置保证所有的设备在默认情况下只有root可以读写

*第二个规则也是比较典型的规则了。它匹配终端设备(tty),然后设置新的权限为0600,所在的组是tty。它也设置了一个特别的设备文件名:%K。在这里例子里,%k代表设备的内核名字。那也就意味着内核识别出这些设备是什么名字,就创建什么样的设备文件名。

*第三行开始的KERNEL=="scd[0-9]*",表示 SCSI CD-ROM 驱动. 它创建一对设备符号连接:cdrom和cdrom-%k。

*第四行,开始的 KERNEL=="hd[a-z]", 表示ATA CDROM驱动器。这个规则创建和上面的规则相同的符号连接。ATA CDROM驱动器需要sysfs值以来区别别的ATA设备,因为SCSI CDROM可以被内核唯一识别。.

*第五行以 ACTION=="add"开始,它告诉udev增加 /sbin/modprobe sg 到命令列表,当任意SCSI设备增加到系统后,这些命令将执行。其效果就是计算机应该会增加sg内核模块来侦测新的SCSI设备。

当然,上面仅仅是一小部分例子,如果你的系统采用了udev方式,那你应该可以看到更多的规则。如果你想修改设备的权限或者创建信的符号连接,那么你需要熟读这些规则,特别是要仔细注意你修改的那些与之相关的设备。

修改你的udev配置

在修改udev配置之前,我们一定要仔细,通常的考虑是:你最好不要修改系统预置的那些规则,特别不要指定影响非常广泛的配置,比如上面例子中的第一行。不正确的配置可能会导致严重的系统问题或者系统根本就无法这个正确的访问设备。

而我们正确的做法应该是在/etc/udev/rules.d/下创建一个信的规则文件。确定你给出的文件的后缀是rules文件名给出的数字序列 应该比 标准配置文件高。比如,你可以创建一个名为99-my-udev.rules的规则文件。在你的规则文件中,你可以指定任何你想修改的配置,比如,假设你 修改修改floppy设备的所在组,还准备创建一个信的符号连接/dev/floppy,那你可以这么写:

KERNEL=="fd[0-9]*", GROUP="users",   SYMLINK+="floppy"

有些发行版本,比如Fedora,采用了外部脚本来修改某些特定设备的属组,组关系和权限。因此上面的改动可能并不见得生效。如果你遇到了这个问题,你就需要跟踪和修改这个脚本来达到你的目的。或者你可以修改PROGRAM或RUN键的值来做到这点。

某些规则的修改可能需要更深的挖掘。比如,你可能想在一个设备上使用sysfs信息来唯一标识一个设备。这些信息最好通过udevinfo命令来获取。

$ udevinfo -a -p $(udevinfo -q path      -n /dev/hda)

上面的命令两次使用udevinfo:一次是返回sysfs设备路径(他通常和我们看到的Linux设备文件名所在路径--/dev/hda--不 同);第 二次才是查询这个设备路径,结果将是非常常的syfs信息汇总。你可以找到最够的信息来唯一标志你的设备,你可以采用适当的替换udev配置文件中的 SYSFS选项。下面的结果就是上面的命令输出

[root@localhost rules.d]# udevinfo -a -p $(udevinfo -q path        -n      /dev/hda1)
Udevinfo starts with the device specified by the devpath and then walks up the chain of
parent devices. It prints for every device found,all possible attributes in the udev rules
key format. A rule to match, can be composed by the attributes of the device and the
attributes from one single parent device.

looking at device '/block/hda/hda1':     
KERNEL=="hda1"     SUBSYSTEM=="block"     DRIVER==""        
ATTR{stat}=="        1133         2268            2            4"         ATTR{size}=="208782"
ATTR{start}=="63"         ATTR{dev}=="3:1"        looking at parent device '/block/hda':   

KERNELS=="hda"     SUBSYSTEMS=="block"     DRIVERS==""        
ATTRS{stat}=="28905 18814 1234781 302540 34087 133247 849708 981336 0 218340 1283968"
ATTRS{size}=="117210240"         ATTRS{removable}=="0"        
ATTRS{range}=="64"         ATTRS{dev}=="3:0"

looking at parent device '/devices/pci0000:00/0000:00:1f.1/ide0/0.0':     

KERNELS=="0.0"     SUBSYSTEMS=="ide"     DRIVERS=="ide-disk"        
ATTRS{modalias}=="ide:m-disk"         ATTRS{drivename}=="hda"       
ATTRS{media}=="disk"       
looking at parent device '/devices/pci0000:00/0000:00:1f.1/ide0':     

KERNELS=="ide0"     SUBSYSTEMS==""     DRIVERS==""       
looking at parent device '/devices/pci0000:00/0000:00:1f.1':     
KERNELS=="0000:00:1f.1"     SUBSYSTEMS=="pci"     DRIVERS=="PIIX_IDE"        
ATTRS{broken_parity_status}=="0"         ATTRS{enable}=="1"        
ATTRS{modalias}=="pci:v00008086d000024CAsv0000144Dsd0000C009bc01sc01i8a"
ATTRS{local_cpus}=="1"         ATTRS{irq}=="11"         ATTRS{class}=="0x01018a"
ATTRS{subsystem_device}=="0xc009"         ATTRS{subsystem_vendor}=="0x144d"
ATTRS{device}=="0x24ca"         ATTRS{vendor}=="0x8086"       
looking at parent device '/devices/pci0000:00':     

KERNELS=="pci0000:00"     SUBSYSTEMS==""     DRIVERS==""






















举一个例子:假设你想修改USB扫描仪的配置。通过一系列的尝试,你已经为这个扫描仪标识了Linux设备文件(每次打开扫描仪时,名字都会变)。你可以 使 用上面的命令替换这个正确的Linux设备文件名,然后定位输出的采用SYSFS{idVendor}行和SYSFS{idProduct}行。最后你可 以使用这些信息来为这个扫描仪创建新的选项。

SYSFS{idVendor}=="0686",   SYSFS{idProduct}=="400e",  
SYMLINK+="scanner", MODE="0664",   group="scanner"

上面的例子表示将扫描仪的组设置为scanner,访问权限设置为0664,同时创建一个/dev/scanner的符号连接。

udev-FAQ

问:udev是什么? 它的目的何在?

答:udev是一种工具,它能够根据系统中的硬件设备的状态动态更新设备文件,包括设备文件的创建,删除等。设备文件通常放在/dev目录下。使用udev后,在/dev目录下就只包含系统中真正存在的设备。

问:udev支持什么内核?

答:udev只支持linux-2.6内核,因为udev严重依赖于sysfs文件系统提供的信息,而sysfs文件系统只在linux-2.6内核中才有。

问:udev是一个内核程序还是用户程序?

答:udev是一个用户程序(user-mode daemon)。

问:udev和devfs有什么差别?

答:udev能够实现所有devfs实现的功能。但udev运行在用户模式中,而devfs运行在内核模式中。据称:devfs具有一些不太容易解决的先天缺陷。

问:udev的配置文件放在哪里?

答:udev是一个用户模式程序。它的配置文件是/etc/udev/udev.conf。这个文件一般缺省有这样几项:

udev_root="/dev" ; udev产生的设备文件的根目录是/dev
udev_db="/dev/.udevdb" ; 通过udev产生的设备文件形成的数据库
udev_rules="/etc/udev/rules.d" ;用于指导udev工作的规则所在目录。
udev_log="err" ;当出现错误时,用syslog记录错误信息。

问:udev的工作过程是怎样的?

答:由于没有研究过udev的源程序,不敢贸然就说udev的工作过程。我只是通过一些网上的资料和udev的说明文档,大致猜测它的工作过程可能是这样的。

当内核检测到在系统中出现了新设备后,内核会在sysfs文件系统中为该新设备生成一项新的记录,一般sysfs文件系统会被mount到/sys目录中。新记录是以一个或多个文件或目录的方式来表示。每个文件都包含有特定的信息。(信息是如何表述的,还要另外研究?)

udev在系统中是以守护进程的方式udevd在运行,它通过某种途径(到底什么途径,目前还没搞懂。)检测到新设备的出现,通过查找设备对应的sysfs中的记录得到设备的一些信息。

udev会根据/etc/udev/udev.conf文件中的udev_rules指定的目录,逐个检查该目录下的文件,这个目录下的文件都是针 对某类或某个设备应该施行什么措施的规则文件。udev读取文件是按照文件名的ASCII字母顺序来读取的,如果udev一旦找到了与新加入的设备匹配的 规则,udev就会根据规则定义的措施对新设备进行配置。同时不再读后续的规则文件。

问:udev的规则文件的语法是怎样的?

答:udev的规则文件以行为单位,以"#"开头的行代表注释行。其余的每一行代表一个规则。每个规则分成一个或多个"匹配"和"赋值"部分。"匹 配"部分用"匹配"专用的关键字来表示,相应的"赋值"部分用"赋值"专用的关键字来表示。"匹配"关键字包 括:ACTION,KERNEL,BUS,SYSFS等等,"赋值"关键字包括:NAME,SYMLINK,OWNER等等。具体详细的描述可以阅读 udev的man文档。

下面举个例子来说明一下,有这样一条规则:SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0d:87:f6:59:f3″, IMPORT="/sbin/rename_netiface %k eth0″
这个规则中的"匹配"部分有三项,分别是SUBSYSTEM,ACTION和SYSFS。而"赋值"部分有一项,是IMPORT。这个规则就是说,当系统 中出现的新硬件属于net子系统范畴,系统对该硬件采取的动作是加入这个硬件,且这个硬件在SYSFS文件系统中的"address"信息等于 "00:0d..."时,对这个硬件在udev层次施行的动作是调用外部程序/sbin/rename_netiface,传递的参数有两个,一个是 "%k",代表内核对该新设备定义的名称。另一个是"eth0"。    从上面这个例子中可以看出,udev的规则的写法比较灵活的,尤其在"匹配"部分中,可以通过诸如"*", "?",[a-c],[1-9]等shell通配符来灵活匹配多个匹配项。具体的语法可以参考udev的man文档。

问:udev怎样做到不管设备连接的顺序而维持一个统一的设备名?

答:实际上,udev是通过对内核产生的设备名增加别名的方式来达到上述目的的。前面说过,udev是用户模式程序,不会更改内核的行为。因此,内 核依然会我行我素地产生设备名如sda,sdb等。但是,udev可以根据设备的其他信息如总线(bus),生产商(vendor)等不同来区分不同的设 备,并产生设备文件。udev只要为这个设备文件取一个固定的文件名就可以解决这个问题。在后续对设备的操作中,只要引用新的设备名就可以了。但为了保证 最大限度的兼容,一般来说,新设备名总是作为一个对内核自动产生的设备名的符号链接(link)来使用的。

例如:内核产生了sda设备名,而根据信息,这个设备对应于是我的内置硬盘,那我就可以制定udev规则,让udev除了产生/dev/sda设备 文件外,另外创建一个符号链接叫/dev/internalHD。这样,我在fstab文件中,就可以用/dev/internalHD来代替原来的 /dev/sda了。下次,由于某些原因,这个硬盘在内核中变成了sdb设备名了,那也不用着急,udev还会自动产生/dev/internalHD这 个链接,并指向正确的/dev/sdb设备。所有其他的文件像fstab等都不用修改。

问:怎样才能找到这些设备信息,并把他们放到udev的规则文件中来匹配呢?

答:这个问题比较难,网上资料不多,我只找到一篇文章来介绍如何写udev的规则。他的基本方法是通过udevinfo这个实用程序来找到那些可以作为规则文件里的匹配项的项目。有这样两种情况可以使用这个工具:

第一种情况是,当你把设备插入系统后,系统为设备产生了设备名(如/dev/sda)。那样的
话,你先用udevinfo -q path -n/dev/sda,命令会产生一个该设备名对应的在sysfs下的路径,如/block/sda。然后,你再用udevinfo -a -p/sys/block/sda,这个命令会显示一堆信息,信息分成很多块。这些信息实际来自于操作系统维护的sysfs链表,不同的块对应不同的路 径。你就可以用这些信息来作为udev规则文件中的匹配项。但需要注意的是,同一个规则只能使用同一块中显示的信息,不能跨块书写规则。

第二种情况是,不知道系统产生的设备名,那就只有到/sys目录下去逐个目录查找了,反复用udevinfo -a -p/sys/path...这个命令看信息,如果对应的信息是这个设备的,那就恭喜你。否则就再换个目录。当然,在这种情况下,成功的可能性比较小。

问: udev和devfs是什么关系
答: udev完全在用户态(userspace)工作,利用设备加入或移除时内核所发送的hotplug事件(event)来工作。关于设备的详细信息是由内 核输出(export)到位于/sys的sysfs文件系统的。所有的设备命名策略、权限控制和事件处理都是在用户态下完成的。与此相反,devfs是作 为内核的一部分工作的。

问: 如果udev不能完成所有devfs的工作的话,为什么把devfs标记为OBSOLETE/removed?

答: 引用 Al Viro (Linux VFS 内核维护者):

-devfs所做的工作被确信可以在用户态来完成。
-devfs被加入内核之时,大家寄望它的质量可以迎头赶上。
-devfs被发现了一些可修复和无法修复的 bug。
-对于可修复的 bug,几个月前就已经被修复了,其维护者认为一切良好。
-对于后者,同样是相当常一段时间以来没有改观了。
-devfs的维护者和作者对它感到失望并且已经停止了对代码的维护工作。

问: 但是当一个并不存在的/dev节点被打开的时候,udev并不能如devfs一样自动加载驱动程序。
答: 的确如此,但Linux的设计是在设备被发现的时候加载模块,而不是当它被访问的时候。

问: 不过等等,我确实希望 udev 可以在不存在的节点被打开的时候自动加载驱动。这是我使用devfs的唯一原因了。给udev 增加这个功能吧。
答: 不,udev 是用来管理/dev 的,不是用来加载内核驱动的。

问: 嗨,求你们了。这不难做到的。
答: 这么个功能对于一个配置正确的计算机是多余的。系统中所有的设备都应该产生hotplug 事件、加载恰当的驱动,而 udev 将会注意到这点并且为它创建对应的设备节点。如果你不想让所有的设备驱动停留在内存之中,应该使用其它东西来管理你的模块(如脚本, modules.conf, 等等) 这不是udev 的工作。

问: 但是我真的喜欢那个功能,还是加上吧
答: devfs用的方法导致了大量无用的modprobe尝试,以此程序探测设备是否存在。每个试探性探测都新建一个运行 modprobe 的进程,而几乎所有这些都是无用的。

问: 我喜欢devfs的设备文件命名方式,udev 可以这样命名么?
答: 可以,udev 可以使用 /dev 的命名策略来创建节点。通过一个配置文件,可以把内核缺省的名字映射到 devfs 的名字。可以看看udev 中带的 udev.rules.devfs 文件。注意: devfs 的命名方式是不被建议并且不被官方支持的,因为它所用的简单枚举设备的方式在设备可能被随时加入或删除的情况下确实是一个比较笨的方法。这些编号代给你的 将只有麻烦,而并不能用来确定设备。看看那个永久性磁盘 (persistentdisk) 的规则就知道如何在用户态下正确的做这件事,而不是傻傻地列出设备。

问: udev 可以为哪些设备创建节点?
答: 所有在 sysfs 中显示的设备都可以由 udev 来创建节点。如果内核中增加了其它设备的支持,udev 也就自动地可以为它们工作了。现在所有的块设备都在被支持之列,大部分的主字符设备也是被支持的。内核开发者们正致力于让所有的字符设备都被支持。可以到 linux-kernel邮件列表上寻找补丁或是查看补丁的状态。

问: udev 是否会去掉匿名设备数量的限制?
答: udev 完全工作于用户态。如果内核支持了更多的匿名设备,udev就会支持。

问: udev 是否会支持符号链接?
答: udev 现在就支持符号链接,每个设备节点拥有多个符号链接也是被支持的。

问: udev如何处理/dev文件系统?
答: 建议使用一个每次启动系统的时候重新创建的 tmpfs 作为 /dev 的文件系统。不过实际上udev并不关心那种文件系统在被使用。

问: 在 init 运行之前,udev 如何处理设备?
答: udev 可以被放入 initramfs 之中,并在每个设备被发现的时候运行。也可以让udev 工作在一个真的根分区被加载之后根据 /sys 的内容创建的初始/dev目录之中。

问: 我是否可以利用 udev 在一个 USB 设备被加载的时候自动加载上这个设备?
答: 技术上讲是可以的,但是 udev 不是用于这个工作的。所有的主流发布版 (distro)都包含了 HAL (http://freedesktop.org/wiki/Software_2fhal) 用于这个工作,它也是专门用于监视设备变更的,并且集成进入了桌面软件。

换个角度说,这可以简单的通过 fstab 来实现:/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0
这样,用户可以用如下命令来访问设备:
$mount /media/PENDRIVE
同样不需要管理员权限,但却拥有了设备的全部访问权限。使用永久性磁盘链接(label, uuid) 将可以指定同一设备,无论其实际上的内核名字是什么。

问: 有什么我需要注意的安全问题么?
答: 当使用动态设备编号的时候,一个给定的主/从设备号可能在不同时间对应不同的设备,如果一个用户拥有对这个节点的访问权限,并且可以创建一个到这个节点的 硬链接,他就可以如此得到一个这个设备节点的拷贝。当设备被移除之后,udev 删除了设备节点,但硬链接依然存在。如果这个设备节点之后被重新使用不同的访问权限被创建的时候,其硬链接仍然可以使用先前的访问权限来访问。(同样的问 题也存在在使用 PAM 改变访问权限的 login 上。)

简单的解决方案就是通过把 /dev 放在 tmpfs 这样的单独的文件系统之上来防止建立硬链接。

问: 我有其他的关于 udev 的问题,我应该问谁?
答: linux-hotplug-devel 正是问这些的地方。邮件列表的地址是linux-hotplug-devel@lists.sourceforge.net



原文链接: http://www.ibm.com/developerworks/cn/linux/l-cn-udev/index.html?ca=drs-cn-0304

概述:

Linux 用户常常会很难鉴别同一类型的设备名,比如 eth0, eth1, sda, sdb 等等。通过观察这些设备的内核设备名称,用户通常能知道这些是什么类型的设备,但是不知道哪一个设备是他们想要的。例如,在一个充斥着本地磁盘和光纤磁盘的设备名清单 (/dev/sd*) 中,用户无法找到一个序列号为"35000c50000a7ef67"的磁盘。在这种情况下,udev 就能动态地在 /dev目录里产生自己想要的、标识性强的设备文件或者设备链接,以此帮助用户方便快捷地找到所需的设备文件。

udev 简介

什么是 udev?

udev 是 Linux2.6 内核里的一个功能,它替代了原来的 devfs,成为当前 Linux 默认的设备管理工具。udev 以守护进程的形式运行,通过侦听内核发出来的 uevent 来管理 /dev目录下的设备文件。不像之前的设备管理工具,udev 在用户空间 (user space) 运行,而不在内核空间 (kernel space) 运行。

使用 udev 的好处:

我们都知道,所有的设备在 Linux 里都是以设备文件的形式存在。在早期的 Linux 版本中,/dev目 录包含了所有可能出现的设备的设备文件。很难想象 Linux 用户如何在这些大量的设备文件中找到匹配条件的设备文件。现在 udev 只为那些连接到 Linux 操作系统的设备产生设备文件。并且 udev 能通过定义一个 udev 规则 (rule) 来产生匹配设备属性的设备文件,这些设备属性可以是内核设备名称、总线路径、厂商名称、型号、序列号或者磁盘大小等等。

  • 动态管理:当设备添加 / 删除时,udev 的守护进程侦听来自内核的 uevent,以此添加或者删除 /dev下的设备文件,所以 udev 只为已经连接的设备产生设备文件,而不会在 /dev下产生大量虚无的设备文件。
  • 自定义命名规则:通过 Linux 默认的规则文件,udev 在 /dev/ 里为所有的设备定义了内核设备名称,比如 /dev/sda、/dev/hda、/dev/fd等等。由于 udev 是在用户空间 (user space) 运行,Linux 用户可以通过自定义的规则文件,灵活地产生标识性强的设备文件名,比如 /dev/boot_disk、/dev/root_disk、/dev/color_printer等等。
  • 设定设备的权限和所有者 / 组:udev 可以按一定的条件来设置设备文件的权限和设备文件所有者 / 组。在不同的 udev 版本中,实现的方法不同,在"如何配置和使用 udev"中会详解。

下面的流程图显示 udev 添加 / 删除设备文件的过程。


图 1. udev 工作流程图:
图 1. udev 工作流程图:

相关术语:

  • 设备文件:由于本文以较通俗的方式讲解 udev,所以设备文件是泛指在 /dev/下,可被应用程序用来和设备驱动交互的文件。而不会特别地区分设备文件、设备节点或者设备特殊文件。
  • devfsdevfs是 Linux 早期的设备管理工具,已经被 udev 取代。
  • sysfssysfs是 Linux 2.6 内核里的一个虚拟文件系统 (/sys)。它把设备和驱动的信息从内核的设备模块导出到用户空间 (userspace)。从该文件系统中,Linux 用户可以获取很多设备的属性。
  • devpath:本文的 devpath是指一个设备在 sysfs文件系统 (/sys)下的相对路径,该路径包含了该设备的属性文件。udev 里的多数命令都是针对 devpath操作的。例如:sdadevpath/block/sda,sda2 的 devpath/block/sda/sda2
  • 内核设备名称:设备在 sysfs里的名称,是 udev 默认使用的设备文件名。

如何配置和使用 udev

下面会以 RHEL4.8 和 RHEL5.3 为平台,分别描述 udev 的配置和使用:

下载和安装 udev

从 Fedora3 和 Red Hat Enterprise4 开始,udev 就是默认的设备管理工具,无需另外下载安装。


清单 1. 检查 udev 在 RHEL4.8 里的版本和运行情况
				
 [root@HOST_RHEL4 dev]# rpm -qa |grep -i udev 
 udev-039-10.29.el4 
 [root@HOST_RHEL4 ~]# uname -r 
 2.6.9-89.ELsmp 
 [root@HOST_RHEL4 ~]# ps -ef |grep udev 
 root     21826     1  0 Dec09 ?        00:00:00 udevd 


清单 2. 检查 udev 在 RHEL5.3 里的版本和运行情况
				
 [root@HOST_RHEL5 ~]# rpm -qa |grep -i udev 
 udev-095-14.19.el5 
 [root@HOST_RHEL5 sysconfig]# uname -r 
 2.6.18-128.el5 
 [root@HOST_RHEL5 sysconfig]# ps -ef|grep udev 
 root      5466     1  0 18:32 ?      00:00:00 /sbin/udevd -d 

如果 Linux 用户想更新 udev 包,可以从 http://www.kernel.org/pub/linux/utils/kernel/hotplug/下载并安装。

udev 的配置文件 (/etc/udev/udev.conf)


清单 3. RHEL 4 . 8下 udev 的配置文件
				
 [root@HOST_RHEL4 dev]# cat /etc/udev/udev.conf 
 # udev.conf 
 # The main config file for udev 
 # 
 # This file can be used to override some of udev's default values 
 # for where it looks for files, and where it places device nodes. 
 # 
 # WARNING: changing any value, can cause serious system breakage! 
 # 

 # udev_root - where in the filesystem to place the device nodes 
 udev_root="/dev/"

 # udev_db - The name and location of the udev database. 
 udev_db="/dev/.udev.tdb"

 # udev_rules - The name and location of the udev rules file 
 udev_rules="/etc/udev/rules.d/"

 # udev_permissions - The name and location of the udev permission file 
 udev_permissions="/etc/udev/permissions.d/"

 # default_mode - set the default mode for all nodes that have no 
 #                explicit match in the permissions file 
 default_mode="0600"

 # default_owner - set the default owner for all nodes that have no 
 #                 explicit match in the permissions file 
 default_owner="root"

 # default_group - set the default group for all nodes that have no 
 #                 explicit match in the permissions file 
 default_group="root"

 # udev_log - set to "yes" if you want logging, else "no"
 udev_log="no"

Linux 用户可以通过该文件设置以下参数:

  • udev_root:udev 产生的设备所存放的目录,默认值是 /dev/。建议不要修改该参数,因为很多应用程序默认会从该目录调用设备文件。
  • udev_db:udev 信息存放的数据库或者所在目录,默认值是 /dev/.udev.tdb
  • udev_rules:udev 规则文件的名字或者所在目录,默认值是 /etc/udev/rules.d/
  • udev_permissions:udev 权限文件的名字或者所在目录,默认值是 /etc/udev/permissions.d/
  • default_mode/ default_owner/ default_group:如果设备文件的权限没有在权限文件里指定,就使用该参数作为默认权限,默认值分别是:0600/root/root
  • udev_log:是否需要 syslog记录 udev 日志的开关,默认值是 no。

清单 4. RHEL5.3 下 udev 的配置文件
				
 [root@HOST_RHEL5 ~]# cat /etc/udev/udev.conf 
 # udev.conf 

 # The initial syslog(3) priority: "err", "info", "debug" or its 
 # numerical equivalent. For runtime debugging, the daemons internal 
 # state can be changed with: "udevcontrol log_priority=<value>". 
 udev_log="err"

udev_logsyslog记录日志的级别,默认值是 err。如果改为 info 或者 debug 的话,会有冗长的 udev 日志被记录下来。

实际上在 RHEL5.3 里,除了配置文件里列出的参数 udev_log外,Linux 用户还可以修改参数 udev_rootudev_rules( 请参考上面的"RHEL4.8 的 udev 配置文件"),只不过这 2 个参数是不建议修改的,所以没显示在 udev.conf 里。

可见该版本的 udev.conf 改动不小:syslog默认会记录 udev 的日志,Linux 用户只能修改日志的级别 (err、info、degub 等 );设备的权限不能在 udev.conf 里设定,而是要在规则文件 (*.rules) 里设定。

通过 udev 设定设备文件的权限

在 RHEL4.8 的 udev,设备的权限是通过权限文件来设置。


清单 5. RHEL4.8 下 udev 的权限文件
				
 [root@HOST_RHEL4 ~]# cat /etc/udev/permissions.d/50-udev.permissions 
......
 # disk devices 
 hd*:root:disk:0660 
 sd*:root:disk:0660 
 dasd*:root:disk:0660 
 ataraid*:root:disk:0660 
 loop*:root:disk:0660 
 md*:root:disk:0660 
 ide/*/*/*/*/*:root:disk:0660 
 discs/*/*:root:disk:0660 
 loop/*:root:disk:0660 
 md/*:root:disk:0660 

 # tape devices 
 ht*:root:disk:0660 
 nht*:root:disk:0660 
 pt[0-9]*:root:disk:0660 
 npt*:root:disk:0660 
 st*:root:disk:0660 
 nst*:root:disk:0660 
......

RHEL4.8 里 udev 的权限文件会为所有常用的设备设定权限和 ownership,如果有设备没有被权限文件设置权限,udev 就按照 udev.conf 里的默认权限值为这些设备设置权限。由于篇幅的限制,上图只显示了 udev 权限文件的一部分,该部分设 置了所有可能连接上的磁盘设备和磁带设备的权限和 ownership。

而在 RHEL5.3 的 udev,已经没有权限文件,所有的权限都是通过规则文件 (*.rules)来设置,在下面的规则文件配置过程会介绍到。

udev 的规则和规则文件

规则文件是 udev 里最重要的部分,默认是存放在 /etc/udev/rules.d/下。所有的规则文件必须以".rules"为后缀名。RHEL 有默认的规则文件,这些默认规则文件不仅为设备产生内核设备名称,还会产生标识性强的符号链接。例如:

 [root@HOST_RHEL5 ~]# ls /dev/disk/by-uuid/ 
 16afe28a-9da0-482d-93e8-1a9474e7245c 

但这些链接名较长,不易调用,所以通常需要自定义规则文件,以此产生易用且标识性强的设备文件或符号链接。

此外,一些应用程序也会在 /dev/下产生一些方便调用的符号链接。例如规则 40-multipath.rules 为磁盘产生下面的符号链接:

 [root@ HOST_RHEL5 ~]# ls /dev/mpath/* 
 /dev/mpath/mpath0  /dev/mpath/mpath0p1  /dev/mpath/mpath0p2 

udev 按照规则文件名的字母顺序来查询全部规则文件,然后为匹配规则的设备管理其设备文件或文件链接。虽然 udev 不会因为一个设备匹配了一条规则而停止解析后面的规则文件,但是解析的顺序仍然很重要。通常情况下,建议让自己想要的规则文件最先被解析。比如,创建一个 名为 /etc/udev/rules.d/10-myrule.rules的文件,并把你的规则写入该文件,这样 udev 就会在解析系统默认的规则文件之前解析到你的文件。

RHEL5.3 的 udev 规则文件比 RHEL4.8 里的更完善。受篇幅的限制,同时也为了不让大家混淆,本文将不对 RHEL4.8 里的规则文件进行详解,下面关于规则文件的配置和实例都是在 RHEL5.3 上进行的。如果大家需要配置 RHEL4 的 udev 规则文件,可以先参照下面 RHEL5.3 的配置过程,然后查询 RHEL4 里的用户手册 (man udev) 后进行配置。

在规则文件里,除了以"#"开头的行(注释),所有的非空行都被视为一条规则,但是一条规则不能扩展到多行。规则都是由多个 键值对(key-value pairs)组成,并由逗号隔开,键值对可以分为 条件匹配键值对( 以下简称"匹配键 ") 和 赋值键值对( 以下简称"赋值键 "),一条规则可以有多条匹配键和多条赋值键。匹配键是匹配一个设备属性的所有条件,当一个设备的属性匹配了该规则里所有的匹配键,就认为这条规则生效,然后按照赋值键的内容,执行该规则的赋值。下面是一个简单的规则:


清单 6. 简单说明键值对的例子
				
 KERNEL=="sda", NAME="my_root_disk", MODE="0660"

KERNEL 是匹配键,NAME 和 MODE 是赋值键。这条规则的意思是:如果有一个设备的内核设备名称为 sda,则该条件生效,执行后面的赋值:在 /dev下产生一个名为 my_root_disk的设备文件,并把设备文件的权限设为 0660。

通过这条简单的规则,大家应该对 udev 规则有直观的了解。但可能会产生疑惑,为什么 KERNEL 是匹配键,而 NAME 和 MODE 是赋值键呢?这由中间的操作符 (operator) 决定。

仅当操作符是"=="或者"!="时,其为匹配键;若为其他操作符时,都是赋值键。

  • RHEL5.3 里 udev 规则的所有操作符:

    "==":比较键、值,若等于,则该条件满足;

    "!=": 比较键、值,若不等于,则该条件满足;

    "=": 对一个键赋值;

    "+=":为一个表示多个条目的键赋值。

    ":=":对一个键赋值,并拒绝之后所有对该键的改动。目的是防止后面的规则文件对该键赋值。

  • RHEL5.3 里 udev 规则的匹配键

    ACTION: 事件 (uevent) 的行为,例如:add( 添加设备 )、remove( 删除设备 )。

    KERNEL: 内核设备名称,例如:sda, cdrom。

    DEVPATH:设备的 devpath 路径。

    SUBSYSTEM: 设备的子系统名称,例如:sda 的子系统为 block。

    BUS: 设备在 devpath 里的总线名称,例如:usb。

    DRIVER: 设备在 devpath 里的设备驱动名称,例如:ide-cdrom。

    ID: 设备在 devpath 里的识别号。

    SYSFS{filename}: 设备的 devpath 路径下,设备的属性文件"filename"里的内容。

    例如:SYSFS{model}=="ST936701SS"表示:如果设备的型号为 ST936701SS,则该设备匹配该 匹配键

    在一条规则中,可以设定最多五条 SYSFS 的 匹配键

    ENV{key}: 环境变量。在一条规则中,可以设定最多五条环境变量的 匹配键

    PROGRAM:调用外部命令。

    RESULT: 外部命令 PROGRAM 的返回结果。例如:

     PROGRAM=="/lib/udev/scsi_id -g -s $devpath", RESULT=="35000c50000a7ef67"
    

    调用外部命令 /lib/udev/scsi_id查询设备的 SCSI ID,如果返回结果为 35000c50000a7ef67,则该设备匹配该 匹配键

  • RHEL5.3 里 udev 的重要赋值键

    NAME/dev下产生的设备文件名。只有第一次对某个设备的 NAME 的赋值行为生效,之后匹配的规则再对该设备的 NAME 赋值行为将被忽略。如果没有任何规则对设备的 NAME 赋值,udev 将使用内核设备名称来产生设备文件。

    SYMLINK:为 /dev/下的设备文件产生符号链接。由于 udev 只能为某个设备产生一个设备文件,所以为了不覆盖系统默认的 udev 规则所产生的文件,推荐使用符号链接。

    OWNER, GROUP, MODE为设备设定权限。

    ENV{key}:导入一个环境变量。

  • RHEL5.3 里 udev 的值和可调用的替换操作符

    在键值对中的键和操作符都介绍完了,最后是值 (value)。Linux 用户可以随意地定制 udev 规则文件的值。例如:my_root_disk, my_printer。同时也可以引用下面的替换操作符:

    $kernel, %k:设备的内核设备名称,例如:sda、cdrom。

    $number, %n:设备的内核号码,例如:sda3 的内核号码是 3。

    $devpath, %p设备的 devpath路径。

    $id, %b设备在 devpath里的 ID 号。

    $sysfs{file}, %s{file}设备的 sysfs里 file 的内容。其实就是设备的属性值。
    例如:$sysfs{size} 表示该设备 ( 磁盘 ) 的大小。

    $env{key}, %E{key}一个环境变量的值。

    $major, %M设备的 major 号。

    $minor %m设备的 minor 号。

    $result, %cPROGRAM 返回的结果。

    $parent, %P:父设备的设备文件名。

    $root, %r:udev_root的值,默认是 /dev/

    $tempnode, %N临时设备名。

    %%符号 % 本身。

    $$符号 $ 本身。



    清单 7. 说明替换操作符的规则例子
    				
     KERNEL=="sd*", PROGRAM="/lib/udev/scsi_id -g -s %p", \
     RESULT=="35000c50000a7ef67", SYMLINK="%k_%c"
    

    该规则的执行:如果有一个内核设备名称以 sd 开头,且 SCSI ID 为 35000c50000a7ef67,则为设备文件产生一个符号链接"sda_35000c50000a7ef67".

制定 udev 规则和查询设备信息的实例:

如何查找设备的信息 ( 属性 ) 来制定 udev 规则:

当我们为指定的设备设定规则时,首先需要知道该设备的属性,比如设备的序列号、磁盘大小、厂商 ID、设备路径等等。通常我们可以通过以下的方法获得:

  • 查询sysfs文件系统:

    前面介绍过,sysfs 里包含了很多设备和驱动的信息。

    例如:设备 sda 的 SYSFS{size} 可以通过 cat /sys/block/sda/size得到;SYSFS{model} 信息可以通过 cat /sys/block/sda/device/model得到。

  • udevinfo命令:

    udevinfo 可以查询 udev 数据库里的设备信息。例如:用 udevinfo 查询设备 sda 的 model 和 size 信息:



    清单 8. 通过 udevinfo 查询设备属性的例子
    				
     [root@HOST_RHEL5 rules.d]# udevinfo -a -p /block/sda | egrep "model|size"
        SYSFS{size}=="71096640"
        SYSFS{model}=="ST936701SS      "
    

  • 其他外部命令

    清单 9. 通过 scsi_id 查询磁盘的 SCSI_ID 的例子
    				
     [root@HOST_RHEL5 ~]# scsi_id -g -s /block/sda 
     35000c50000a7ef67 
    

udev 的简单规则:


清单 10. 产生网卡设备文件的规则
				
 SUBSYSTEM=="net", SYSFS{address}=="AA:BB:CC:DD:EE:FF", NAME="public_NIC"

该规则表示:如果存在设备的子系统为 net,并且地址 (MAC address) 为"AA:BB:CC:DD:EE:FF",为该设备产生一个名为 public_NIC 的设备文件。


清单 11. 为指定大小的磁盘产生符号链接的规则
				
 SUBSYSTEM=="block", SYSFS{size}=="71096640", SYMLINK ="my_disk"

该规则表示:如果存在设备的子系统为 block,并且大小为 71096640(block),则为该设备的设备文件名产生一个名为 my_disk 的符号链接。


清单 12. 通过外部命令为指定序列号的磁盘产生设备文件的规则
				
 KERNEL=="sd*[0-9]", PROGRAM=="/lib/udev/scsi_id -g -s %p", \
 RESULT=="35000c50000a7ef67", NAME +="root_disk%n"

该规则表示:如果存在设备的内核设备名称是以 sd 开头 ( 磁盘设备 ),以数字结尾 ( 磁盘分区 ),并且通过外部命令查询该设备的 SCSI_ID 号为"35000c50000a7ef67",则产生一个以 root_disk 开头,内核号码结尾的设备文件,并替换原来的设备文件(如果存在的话)。例如:产生设备名 /dev/root_disk2,替换原来的设备名 /dev/sda2

运用这条规则,可以在 /etc/fstab里保持系统分区名称的一致性,而不会受驱动加载顺序或者磁盘标签被破坏的影响,导致操作系统启动时找不到系统分区。

其他常用的 udev 命令:

  • udevtest:

    udevtest会针对一个设备,在不需要 uevent 触发的情况下模拟一次 udev的运行,并输出查询规则文件的过程、所执行的行为、规则文件的执行结果。通常使用 udevtest来调试规则文件。以下是一个针对设备 sda 的 udevtest例子。由于 udevtest是扫描所有的规则文件 ( 包括系统自带的规则文件 ),所以会产生冗长的输出。为了让读者清楚地了解 udevtest,本例只在规则目录里保留一条规则:



    清单 13. 为 udevtest 保留的规则
    				
     KERNEL=="sd*", PROGRAM="/lib/udev/scsi_id -g -s %p", RESULT=="35000c50000a7ef67", \
     NAME="root_disk%n", SYMLINK="symlink_root_disk%n"
    



    清单 14. udevtest 的执行过程
    				
     [root@HOST_RHEL5 rules.d]# udevtest /block/sda 
     main: looking at device '/block/sda' from subsystem 'block'
     run_program: '/lib/udev/scsi_id -g -s /block/sda'
     run_program: '/lib/udev/scsi_id' (stdout) '35000c50000a7ef67'
     run_program: '/lib/udev/scsi_id' returned with status 0 
     udev_rules_get_name: reset symlink list 
     udev_rules_get_name: add symlink 'symlink_root_disk'
     udev_rules_get_name: rule applied, 'sda' becomes 'root_disk'
     udev_device_event: device '/block/sda' already in database, \
                      validate currently present symlinks 
     udev_node_add: creating device node '/dev/root_disk', major = '8', \
                minor = '0', mode = '0660', uid = '0', gid = '0'
     udev_node_add: creating symlink '/dev/symlink_root_disk' to 'root_disk'
    

    可以看出,udevtest对 sda 执行了外部命令 scsi_id, 得到的 stdout 和规则文件里的 RESULT 匹配,所以该规则匹配。然后 ( 模拟 ) 产生设备文件 /dev/root_disk和符号链接 /dev/symlink_root_disk,并为其设定权限。

  • start_udev:

    start_dev命令重启 udev守护进程,并对所有的设备重新查询规则目录下所有的规则文件,然后执行所匹配的规则里的行为。通常使用该命令让新的规则文件立即生效:



    清单 15. start_udev 的执行过程
    				
     [root@HOST_RHEL5 rules.d]# start_udev 
     Starting udev:                                             [  OK  ] 
    

    start_udev一般没有标准输出,所有的 udev 相关信息都按照配置文件 (udev.conf)的参数设置,由 syslog记录。

小结:

udev 是高效的设备管理工具,其最大的优势是动态管理设备和自定义设备的命名规则,因此替代 devfs 成为 Linux 默认的设备管理工具。通过阅读本文,Linux 用户能够了解到 udev 的工作原理和流程,灵活地运用 udev 规则文件,从而方便地管理 Linux 设备文件。


参考资料

原文链接:http://ilinuxkernel.com/?p=462

在 Linux系统中,若存在多块硬盘,通常内核分配盘符的顺序是/dev/sda、/dev/sdb、/dev/sdc ... ...。在系统启动过程中,内核会按照扫描到硬盘的顺序分配盘符。在系统启动后,热插拔硬盘硬盘,系统会顺序分配盘符。在同一个硬盘槽位,每次插入硬盘后,在 系统中的盘符都可能不一致。第一次插入时,盘符可能为/dev/sdb,将硬盘拔除后,再次插入硬盘,盘符可能变为/dev/sde,出现盘符漂移。

假设机器上有6个硬盘槽位,槽位号分别为0~5。其中1、2、5槽位有硬盘,则Linux系统后

x 0 √ 2 x 4
√ 1 x 3 √ 5

所得到的系统盘符对应关系为:1槽位的硬盘盘符为/dev/sda,2槽位的硬盘盘符为/dev/sdb,3槽位的硬盘盘符为/dev/sdc。

x 0  sdb 2 x 4
sda 1 x 3 sdc 5


系统启动后,我们热插拔硬盘,将一块硬盘插入3槽位,则该硬盘的盘符为/dev/sdd。

x 0 sdb 2 x 4
sda 1 sdd 3 sdc 5



再分别在0和4槽位插入硬盘,则系统盘符为:

sde 0 sdb 2 sdf 4
sda 1 sdd 3 sdc 5



从上面,我们可以可以看出,Linux分配给硬盘的盘符与所在槽位没有关系,只与插入硬盘的顺序有关。


同时即使在同一槽位的硬盘,也会存在盘符漂移现象。如,当系统中有进程正在读写磁盘/dev/sdd,若此时我们将该硬盘拔除,稍后将硬盘插入,此时得到的盘符可能为/dev/sdg,而不是所希望的/dev/sdd。

sde 0 sdb 2 sdf 4
sda 1 sdg 3 sdc 5
盘符漂移现象,给用户带来很大不便,尤其是使用裸设备的用户。


原文地址: http://www.itpub.net/thread-1404451-1-1.html

问题描述
服务器突然故障死机,导致数据库无法驱动,redo的CURRENT组的损坏。oracle 10g rac环境,asm磁盘组,redhat linux系统。每个组一个成员这个是组被破坏无法修复的关键。
没有归档,没有备份。使用ASM无法将数据文件冷备份出来。
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 254606 change 12131176305969 time 03/08/2011 01:03:00
ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'
查看日志组文件信息,报错的日志组为CURRENT模式。
SQL> select group#,sequence#,archived,status from v$log;

    GROUP#  SEQUENCE# ARC STATUS
---------- ---------- --- ----------------
         1      17495 NO  INACTIVE
         2      17496 NO  CURRENT
         3      17365 NO  INACTIVE
         4      17366 NO  CURRENT

组成员只有一个。

SQL>


     Group   Instance             Member             STATUS             Size(MB)
---------- ---------- ------------------------------ ---------------- ----------
         1          1 +DG1/police/onlinelog/group_1. INACTIVE                500
                      257.657430665

         2          1 +DG1/police/onlinelog/group_2. CURRENT                 500
                      258.657430669

         3          2 +DG1/police/onlinelog/group_3. INACTIVE                500
                      265.657431819

         4          2 +DG1/police/onlinelog/group_4. CURRENT                 500
                      266.657431825

无法使用clear命令清楚redo的信息
SQL> alter database clear unarchived logfile group 2   
  2  ;
alter database clear unarchived logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)
ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'

SQL> alter database clear logfile group 2;
alter database clear logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)
ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'

处理步骤

把数据库down掉
   SQL>shutdown immediate

5、在init<sid>.ora中加入如下参数
_allow_resetlogs_corruption=TRUE

6、重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
如果出错,不再理会,发出
SQL>alter database open resetlogs;
如果运气好的话可以正常启动数据库,就可以导出数据了。但是这里有点意外不知道是点背还是rac环境的恢复比较特殊。在alert.log中有如下报错:

Errors in file /u01/app/oracle/admin/police/bdump/police2_j003_17720.trc:
ORA-00600: internal error code, arguments: [4194], [9], [8], [], [], [], [], []
Wed Mar  9 18:08:06 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_j004_17722.trc:
ORA-00600: internal error code, arguments: [4193], [55749], [55753], [], [], [], [], []
Wed Mar  9 18:08:08 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_mmon_11328.trc:
ORA-00600: internal error code, arguments: [4194], [12], [17], [], [], [], [], []
Wed Mar  9 18:08:08 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_j002_17718.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

能后我就重复启动数据库这个错误就过去了,网上有一篇文档是这么说的,真的可以过去,不过我是将两个节点都同时启动的时候过去的,但是在开始出现如下错误:
ORA-600[KCLCHKBLK_4]【2824】,但是没有出现ORA-600[2662]的报错,不知道为什么,有人说是temp文件不一致造成,但是别人都有2662的报错我这里没有,不管了先将temp删了在说。
能后速度将temp删除,能后发现问题依旧。当时我就很失望了,情绪低落。这个报错在网上的解决办法只有这一个。也没有什么人有更好的建议。
ORA-00600: internal error code, arguments: [kclchkblk_4], [2824], [18446744071603238605], [2824], [18446744071593491338], [], [], []
Wed Mar  9 14:29:55 2011
Errors in file /u01/app/oracle/admin/police/udump/police1_ora_27660.trc:
ORA-00600: internal error code, arguments: [kclchkblk_4], [2824], [18446744071603238605], [2824], [18446744071593491338], [], [], []
Wed Mar  9 14:29:55 2011
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600

但是仔细观察后我发现18446744071593491338这个数据有问题,它在我每次重新启动数据库的时候会和前面的数值有所改变18446744071593491338,我的目标就是将
这个数值尽量的缩小和18446744071603238605的值,重复几遍后发现使用srvctl start database -d sid数据库会自动重启多次,我就不停地启动关闭。有希望了两个者还是相差太大,
这一步我们在这里卡了很久。这里有一个scn的问题,我这里碰到的是后面的比前面的低,所以adjust_scn没有效果。
无赖我将_allow_resetlogs_corruption=TRUE增加到spfile中让数据库同时启动。结果发现错误改变了,后来想想估计是要将参数添加到spfile中同时启动数据库才有效果,因为我单独启动数据库的时候效果不大。
Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Wed Mar  9 18:08:35 2011
ORACLE Instance police2 (pid = 16) - Error 600 encountered while recovering transaction (9, 46).
Wed Mar  9 18:08:35 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Wed Mar  9 18:08:35 2011
Trace dumping is performing id=[cdmp_20110309180835]
Wed Mar  9 18:08:37 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/admin/police/bdump/police2_p007_19333.trc:
ORA-00600: internal error code, arguments: [4198], [9], [], [], [], [], [], []
出现了这些报错,现在好了,4137,4138 ,4139不都是undo的报错吧,
新建立两个undo,修改spfile使用新的undo启动,删除旧的undo。
添加spfile参数
_allow_resetlogs_corruption"=true "
_allow_terminal_recovery_corruption"=true
_corrupted_rollback_segments ='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$'
如果不能确定多少个,但是我在删除UNDO的时候提示_SYSSMU2无法删除,我还是坚持加到了20个,后来我查了一下一共有400多个还好没有每个都坏掉。
修改undo_management 这个参数
把参数文件中的undo_management 改为MANUAL
create undo tablespace undotbs3 datafile '/opt/oracle/oradata/conner/undotbs3.dbf' size 10M;
Tablespace created.
SQL> alter system set undo_tablespace=undotbs1 scope=spfile sid='sid';
System altered.
SQL> drop tablespace undotbs2;
Tablespace dropped.

将两个节点的undo都替换后发现数据库可以起来了,但还是有报错,
Errors in file /u01/app/oracle/admin/police/bdump/police2_j000_7977.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Wed Mar  9 23:56:10 2011
但还好可以exp数据了。

导出数据后,删除数据库,删除asm,
关闭第二台的asm实例,
登入第一台asm
SQL> select name from v$asm_diskgroup;
NAME
------------------------------
DG1
SQL> drop diskgroup DG1 including contents;       -->删除磁盘组
SQL>SHUTDOWN IMMEDIATE
能后
crs_unregister ora.node1.ASM1.asm
crs_unregister ora.node1.ASM1.asm(后来极度后悔,应该在unregister前备份一下就好了)
在dbs和admin下删除asm相关文档
修改/etc/oratab文件将asm的注释。
dbca重新建立asm磁盘发现asm实例无法启动晕倒。好像是出现prks-1011,和ora-0210的报错
使用srvctl add asm -n node1 -i +ASM1 -o $ORACLE_HOME -p init+ASM1.ora
提示ora.node1.ASM1.asm服务已经存在了,但是crs_stat -t查看又没有ora.node1.ASM1.asm服务。
于是我使用crs_register ora.node1.ASM1.asm的时候提示找不到 ora.node1.ASM1.asm.cap的文件(这里折腾了一段时间)
没法我从别的rac上使用crs_stat -p ora.node1.ASM1.asm > ora.node1.ASM1.asm.cap导出了一份拷贝到提示的目录下,并且修改了文件中的主机信息等。
在使用crs_register ora.node1.ASM1.asm就注册成功了。其实 ora.node1.ASM1.asm.cap这个文件的东西和 ora.node1.lsnr的文件内容一样。就是有些东西自己动手修改一下就可以替代了。
重新建库导入文件

艰苦的数据恢复终于完成了。


ORA-00600 kcbnew_3错误案例一则

原文出处: http://qqmengxue.itpub.net/post/42175/509361

这则案例给出了一个常规的思路,跟踪文件也说明了内部错误的信息,摘录于此:

环境:

oracle 9.2.0.5
System name: HP-UX


今天客户报账说访问核心任务表报ORA-01410: invalid ROWID错误:

SQL> SELECT /*+FULL(A)*/ COUNT(*) FROM CC09MAIN04.CRM_CAMPAIGN_TASK_1122 A;

SELECT /*+FULL(A)*/ COUNT(*) FROM CC09MAIN04.CRM_CAMPAIGN_TASK_1122 A

ORA-01410: invalid ROWID

通过设置10200事件后发现访问23/1630块的时候停止并报错:

SQL> alter session set max_dump_file_size=unlimited;

SQL> alter session set db_file_multiblock_read_count=1;

SQL> alter session set events 'immediate trace name trace_buffer_on level 1048576';

SQL> alter session set events '10200 trace name context forever, level 1';
SQL> SELECT /*+FULL(A)*/ COUNT(*) FROM CC09MAIN04.CRM_CAMPAIGN_TASK_1122 A;

    ERROR at line 1:
    ORA-01410: invalid ROWID

SQL> alter session set events 'immediate trace name trace_buffer_off';

导出这个块查看发现很有诡异:

1、这个块存储的 seg/obj: 0x1d834 (120884)

但是我们这个表的objid是121021:

SQL> select object_id,data_object_id from dba_objects t where t.owner='CC09MAIN04' and t.object_name='CRM_CAMPAIGN_TASK_1122';

OBJECT_ID DATA_OBJECT_ID
---------- --------------
121021 121021

根据objid为121021的查看是哪个表:
SQL> select object_id,object_name,object_type from dba_objects t where t.object_id=120884;

OBJECT_ID OBJECT_NAME OBJECT_TYPE
---------- -------------------------------------------------------------------------------- ------------------
120884 CRM_CUS_YWY_DATACLEAN_HC TABLE

很显然,这个数据块里存储的数据已经发生了窜位,原本属于'CRM_CAMPAIGN_TASK_1122'的块居然存储了别人的信息。

然后我们在返回去剖析ORA-01410错误的原因,

因为'CRM_CAMPAIGN_TASK_1122'表的某一个ROWID对应的数据块已经窜位,里面存储的数据已经变成了其他他表的数据,当进行全表扫描到此块的时候,根据rowid取数据发现居然是一个空的数据,然后oracle就报:0ra-01410错误了。

数据库居然有这么严重的错误,通过查看ALTER文件发现在昨晚凌晨有人做了一些操作引起了ORA-600错误:

ARC0: Completed archiving log 4 thread 1 sequence 25804
Mon Nov 22 01:18:16 2010
Errors in file /home/oracle/app/oracle/admin/aic/udump/aic1_ora_15119.trc:
ORA-00600: internal error code, arguments: [kcbnew_3], [8], [], [], [], [], [], []
Mon Nov 22 01:18:47 2010
Trace dumping is performing id=[cdmp_20101122011847]
Mon Nov 22 01:26:03 2010

/home/oracle/app/oracle/admin/aic/udump/aic1_ora_15119.trc
*** 2010-11-22 01:18:16.819
*** SESSION ID:(218.5127) 2010-11-22 01:18:16.803
BH (0xc0000000e2f62140) file#: 23 rdba: 0x05c00679 (23/1657) class 1 ba: 0xc0000000e2c74000
set: 12 dbwrid: 0 obj: 120884 objn: 120884
hash: [c000000105f612a0,c000000134e29548] lru: [c0000000c6f4cba8,c0000000f7f3e2c8]
ckptq: [NULL] fileq: [NULL]
st: XCURRENT md: NULL rsop: 0x0000000000000000 tch: 1
flags: gotten_in_current_mode block_written_once redo_since_read
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [1] RRBA: [0x0.0.0]
GLOBAL CACHE ELEMENT DUMP (address: 0xc0000000edfb6500):
id1: 0x5c00679 id2: 0x0 lock: XL rls: 0x000 acq: 0x00
open: 1 flags: 0x1 fair: 0 recovery: 0 latch: 26
bscn: 0.0 bctx: 0x0000000000000000 write: 0 cscn: 0:0
xflg: 0 xid: 0x0000.000.00000000
lcp: 0x0000000000000000 lnk: [NULL] lch: [c0000000e2f62248,c0000000e2f62248]
seq: 30193 113:5:1 143:0:0 325:5 450:1 329:0 48:3:1 1:3:1 260:3 144:0:0 192:3:0 450:1 329:0 48:3:1 1:3:1 144:0:0 98:3:0
LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE LOCK:
flg: 0x02202000 state: XCURRENT mode: NULL waiters: 0 foq: 0 addr: 0xc0000000e2f62140
obj: 120884 cls: DATA bscn: a52.ce6857fc
GCS SHADOW handle 0xc0000000edfb6598,4024 sq[0xc000000136987de0,0xc000000136987de0] resp[0xc000000136987db8,0x5c00679.0]
grant 5 cvt 0 mdrole 0x6 st 0x40 GRANTQ rl LOCAL
master 0 owner 0 remote[0x0000000000000000,0] hist 0x118c106
history 0x6.0x4.0xc.0x6.0x1.0x0. cflag 0x0 flags 0x0
disk: 0x0000.00000000 write request: 0x0000.00000000
pi scn: 0x0000.00000000
msgseq 0x0 updseq 0x0 reqids[4102,0,0] infop 0x0
GCS RESOURCE 0xc000000136987db8 hashq [0xc00000013678c338,0xc000000136ecbe50] name[0x5c00679,0x0]
grant 0xc0000000edfb6598 cvt 0x0000000000000000 send 0x0000000000000000,0 write 0x0000000000000000,0
flag 0x0 mdrole 0x2 mode 5 scan 0 role LOCAL
disk: 0x0000.00000000 write: 0x0000.00000000 cnt 0x0 hist 0x0
xid 0x0000.000.00000000
HV bucket info: idx 600 stat 0 last rem inc 30
master 0, tobe_master 0, prev master 32767
GCS SHADOW handle 0xc0000000edfb6598,4024 sq[0xc000000136987de0,0xc000000136987de0] resp[0xc000000136987db8,0x5c00679.0]
grant 5 cvt 0 mdrole 0x6 st 0x40 GRANTQ rl LOCAL
master 0 owner 0 remote[0x0000000000000000,0] hist 0x118c106
history 0x6.0x4.0xc.0x6.0x1.0x0. cflag 0x0 flags 0x0
disk: 0x0000.00000000 write request: 0x0000.00000000
pi scn: 0x0000.00000000
msgseq 0x0 updseq 0x0 reqids[4102,0,0] infop 0x0
kjbmbassert [0x5c00679.0]
kjbmsassert(0x5c00679.0)(1)
*** 2010-11-22 01:18:16.826
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcbnew_3], [8], [], [], [], [], [], []
Current SQL statement for this session:
-- Create/Recreate indexes
create index temp_mobile on TMP_CUSTOMER (yjdh)
----- Call Stack Trace -----

oracle官方解释:

PURPOSE:
This article discusses the internal error "ORA-600 [kcbnew_3]", what
it means and possible actions. The information here is only applicable
to the versions listed and is provided only for guidance.

ERROR:
ORA-600 [kcbnew_3] [a] [b] [c]

VERSIONS:
versions 9.2 and later

DESCRIPTION:

A cache buffer holding a database block is in the process of
being reused.

The buffer is in state "current" and may be reused only if the object
is of type temp or undo.

The consistency check comparing the block class in the buffer header
with the block class passed to the cache by the caller is failing.

ARGUMENTS:

The number of arguments and their meaning vary depending on the Oracle
Server release.

Oracle 10.1 and later:

Arg [a] Internal loop counter (number of blocks to new)
Arg [b] Buffer class
Arg [c] Object Id passed to the cache by the layer accessing the cache

Oracle Release 9.2 and earlier:

Arg [a] Buffer class

FUNCTIONALITY:
Kernel Cache Buffer management Implementation

IMPACT:
PROCESS FAILURE
MEMORY CORRUPTION
NON CORRUPTIVE - No underlying data corruption.

SUGGESTIONS:

If the Known Issues section below does not help in terms of identifying
a solution, please submit the trace files and alert.log to Oracle
Support Services for further analysis.

Known Issues:

最后解决: 只有将数据进行异机恢复,打补丁!


原文出处: http://walkoven.com/?p=57

下载: http://walkoven.com/hbase optimization and apply summary in taobao.pdf

1 前言
hbase是从hadoop中分离出来的apache顶级开源项目。由于它很好地用java实现了google的bigtable系统大部分特性,因此在 数据量猛增的今天非常受到欢迎。对于淘宝而言,随着市场规模的扩大,产品与技术的发展,业务数据量越来越大,对海量数据的高效插入和读取变得越来越重要。 由于淘宝拥有也许是国内最大的单一hadoop集群(云梯),因此对hadoop系列的产品有比较深入的了解,也就自然希望使用hbase来做这样一种海 量数据读写服务。本篇文章将对淘宝最近一年来在online应用上使用和优化hbase的情况做一次小结。

2 原因
为什么要使用hbase?
淘宝在2011年之前所有的后端持久化存储基本上都是在mysql上进行的(不排除少量oracle/bdb/tair/mongdb等),mysql由于开源,并且生态系统良好,本身拥有分库分表等多种解决方案,因此很长一段时间内都满足淘宝大量业务的需求。
但是由于业务的多样化发展,有越来越多的业务系统的需求开始发生了变化。一般来说有以下几类变化:
a) 数据量变得越来越多,事实上现在淘宝几乎任何一个与用户相关的在线业务的数据量都在亿级别,每日系统调用次数从亿到百亿都有,且历史数据不能轻易删除。这需要有一个海量分布式文件系统,能对TB级甚至PB级别的数据提供在线服务
b) 数据量的增长很快且不一定能准确预计,大多数应用系统从上线起在一段时间内数据量都呈很快的上升趋势,因此从成本的角度考虑对系统水平扩展能力有比较强烈的需求,且不希望存在单点制约
c) 只需要简单的kv读取,没有复杂的join等需求。但对系统的并发能力以及吞吐量、响应延时有非常高的需求,并且希望系统能够保持强一致性
d) 通常系统的写入非常频繁,尤其是大量系统依赖于实时的日志分析
e) 希望能够快速读取批量数据
f ) schema灵活多变,可能经常更新列属性或新增列
g) 希望能够方便使用,有良好且语义清晰的java接口

以上需求综合在一起,我们认为hbase是一种比较适合的选择。首先它的数据由hdfs天然地做了数据冗余,云梯三年的稳定运行,数据100%可靠 己经证明了hdfs集群的安全性,以及服务于海量数据的能力。其次hbase本身的数据读写服务没有单点的限制,服务能力可以随服务器的增长而线性增长, 达到几十上百台的规模。LSM-Tree模式的设计让hbase的写入性能非常良好,单次写入通常在1-3ms内即可响应完成,且性能不随数据量的增长而 下降。region(相当于数据库的分表)可以ms级动态的切分和移动,保证了负载均衡性。由于hbase上的数据模型是按rowkey排序存储的,而读 取时会一次读取连续的整块数据做为cache,因此良好的rowkey设计可以让批量读取变得十分容易,甚至只需要1次io就能获取几十上百条用户想要的 数据。最后,淘宝大部分工程师是java背景的同学,因此hbase的api对于他们来说非常容易上手,培训成本相对较低。
当然也必须指出,在大数据量的背景下银弹是不存在的,hbase本身也有不适合的场景。比如,索引只支持主索引(或看成主组合索引),又比如服务是单点 的,单台机器宕机后在master恢复它期间它所负责的部分数据将无法服务等。这就要求在选型上需要对自己的应用系统有足够了解。

3 应用情况
我们从2011年3月开始研究hbase如何用于在线服务。尽管之前在一淘搜索中己经有了几十节点的离线服务。这是因为hbase早期版本的目标就是一个 海量数据中的离线服务。2009年9月发布的0.20.0版本是一个里程碑,online应用正式成为了hbase的目标,为此hbase引入了 zookeeper来做为backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一个里程碑,基本上我们今天 看到的各大网站,如facebook/ebay/yahoo内所使用于生产的hbase都是基于这一个版本(fb所采用的0.89版本结构与0.90.x 相近)。bloomfilter等诸多属性加入了进来,性能也有极大提升。基于此,淘宝也选用了0.90.x分支作为线上版本的基础。
第一个上线的应用是数据魔方中的prom。prom原先是基于redis构建的,因为数据量持续增大以及需求的变化,因此我们用hbase重构了它的存储 层。准确的说prom更适合0.92版本的hbase,因为它不仅需要高速的在线读写,更需要count/group by等复杂应用。但由于当时0.92版本尚未成熟,因此我们自己单独实现了coprocessor。prom的数据导入是来源于云梯,因此我们每天晚上花 半个小时将数据从云梯上写入hbase所在的hdfs,然后在web层做了一个client转发。经过一个月的数据比对,确认了速度比之redis并未有 明显下降,以及数据的准确性,因此得以顺利上线。
第二个上线的应用是TimeTunnel,TimeTunnel是一个高效的、可靠的、可扩展的实时数据传输平台,广泛应用于实时日志收集、数据实时监 控、广告效果实时反馈、数据库实时同步等领域。它与prom相比的特点是增加了在线写。动态的数据增加使hbase上compact/balance /split/recovery等诸多特性受到了极大的挑战。TT的写入量大约一天20TB,读的量约为此的1.5倍,我们为此准备了20台 regionserver的集群,当然底层的hdfs是公用的,数量更为庞大(下文会提到)。每天TT会为不同的业务在hbase上建不同的表,然后往该 表上写入数据,即使我们将region的大小上限设为1GB,最大的几个业务也会达到数千个region这样的规模,可以说每一分钟都会有数次 split。在TT的上线过程中,我们修复了hbase很多关于split方面的bug,有好几个commit到了hbase社区,同时也将社区一些最新 的patch打在了我们的版本上。split相关的bug应该说是hbase中会导致数据丢失最大的风险之一,这一点对于每个想使用hbase的开发者来 说必须牢记。hbase由于采用了LSM-Tree模型,从架构原理上来说数据几乎没有丢失的可能,但是在实际使用中不小心谨慎就有丢失风险。原因后面会 单独强调。TT在预发过程中我们分别因为Meta表损坏以及split方面的bug曾经丢失过数据,因此也单独写了meta表恢复工具,确保今后不发生类 似问题(hbase-0.90.5以后的版本都增加了类似工具)。另外,由于我们存放TT的机房并不稳定,发生过很多次宕机事故,甚至发生过假死现象。因 此我们也着手修改了一些patch,以提高宕机恢复时间,以及增强了监控的强度。
CTU以及会员中心项目是两个对在线要求比较高的项目,在这两个项目中我们特别对hbase的慢响应问题进行了研究。hbase的慢响应现在一般归纳为四 类原因:网络原因、gc问题、命中率以及client的反序列化问题。我们现在对它们做了一些解决方案(后面会有介绍),以更好地对慢响应有控制力。
和Facebook类似,我们也使用了hbase做为实时计算类项目的存储层。目前对内部己经上线了部分实时项目,比如实时页面点击系统,galaxy实 时交易推荐以及直播间等内部项目,用户则是散布到公司内各部门的运营小二们。与facebook的puma不同的是淘宝使用了多种方式做实时计算层,比如 galaxy是使用类似affa的actor模式处理交易数据,同时关联商品表等维度表计算排行(TopN),而实时页面点击系统则是基于twitter 开源的storm进行开发,后台通过TT获取实时的日志数据,计算流将中间结果以及动态维表持久化到hbase上,比如我们将rowkey设计为 url+userid,并读出实时的数据,从而实现实时计算各个维度上的uv。
最后要特别提一下历史交易订单项目。这个项目实际上也是一个重构项目,目的是从以前的方案上迁移到hbase上来。由于它关系到己买到页面,用户使用频率 非常高,重要程度接近核心应用,对数据丢失以及服务中断是零容忍。它对compact做了优化,避免大数据量的compact在服务时间内发生。新增了定 制的filter来实现分页查询,rowkey上对应用进行了巧妙的设计以避免了冗余数据的传输以及90%以上的读转化成了顺序读。目前该集群存储了超过 百亿的订单数据以及数千亿的索引数据,线上故障率为0。
随着业务的发展,目前我们定制的hbase集群己经应用到了线上超过二十个应用,数百台服务器上。包括淘宝首页的商品实时推荐、广泛用于卖家的实时量子统计等应用,并且还有继续增多以及向核心应用靠近的趋势。

4 部署、运维和监控
Facebook之前曾经透露过Facebook的hbase架构,可以说是非常不错的。如他们将message服务的hbase集群按用户分为数个集 群,每个集群100台服务器,拥有一台namenode以及分为5个机架,每个机架上一台zookeeper。可以说对于大数据量的服务这是一种优良的架 构。对于淘宝来说,由于数据量远没有那么大,应用也没有那么核心,因此我们采用公用hdfs以及zookeeper集群的架构。每个hdfs集群尽量不超 过100台规模(这是为了尽量限制namenode单点问题)。在其上架设数个hbase集群,每个集群一个master以及一个 backupmaster。公用hdfs的好处是可以尽量减少compact的影响,以及均摊掉硬盘的成本,因为总有集群对磁盘空间要求高,也总有集群对 磁盘空间要求低,混合在一起用从成本上是比较合算的。zookeeper集群公用,每个hbase集群在zk上分属不同的根节点。通过zk的权限机制来保 证hbase集群的相互独立。zk的公用原因则仅仅是为了运维方便。
由于是在线应用,运维和监控就变得更加重要,由于之前的经验接近0,因此很难招到专门的hbase运维人员。我们的开发团队和运维团队从一开始就很重视该问题,很早就开始自行培养。以下讲一些我们的运维和监控经验。
我们定制的hbase很重要的一部分功能就是增加监控。hbase本身可以发送ganglia监控数据,只是监控项远远不够,并且ganglia的展示方 式并不直观和突出。因此一方面我们在代码中侵入式地增加了很多监控点,比如compact/split/balance/flush队列以及各个阶段的耗 时、读写各个阶段的响应时间、读写次数、region的open/close,以及具体到表和region级别的读写次数等等。仍然将它们通过 socket的方式发送到ganglia中,ganglia会把它们记录到rrd文件中,rrd文件的特点是历史数据的精度会越来越低,因此我们自己编写 程序从rrd中读出相应的数据并持久化到其它地方,然后自己用js实现了一套监控界面,将我们关心的数据以趋势图、饼图等各种方式重点汇总和显示出来,并 且可以无精度损失地查看任意历史数据。在显示的同时会把部分非常重要的数据,如读写次数、响应时间等写入数据库,实现波动报警等自定义的报警。经过以上措 施,保证了我们总是能先于用户发现集群的问题并及时修复。我们利用redis高效的排序算法实时地将每个region的读写次数进行排序,能够在高负载的 情况下找到具体请求次数排名较高的那些region,并把它们移到空闲的regionserver上去。在高峰期我们能对上百台机器的数十万个 region进行实时排序。
为了隔离应用的影响,我们在代码层面实现了可以检查不同client过来的连接,并且切断某些client的连接,以在发生故障时,将故障隔离在某个应用内部而不扩大化。mapreduce的应用也会控制在低峰期运行,比如在白天我们会关闭jobtracker等。
此外,为了保障服务从结果上的可用,我们也会定期跑读写测试、建表测试、hbck等命令。hbck是一个非常有用的工具,不过要注意它也是一个很重的工操 作,因此尽量减少hbck的调用次数,尽量不要并行运行hbck服务。在0.90.4以前的hbck会有一些机率使hbase宕机。另外为了确保hdfs 的安全性,需要定期运行fsck等以检查hdfs的状态,如block的replica数量等。
我们会每天根踪所有线上服务器的日志,将错误日志全部找出来并且邮件给开发人员,以查明每一次error以上的问题原因和fix。直至错误降低为0。另外 每一次的hbck结果如果有问题也会邮件给开发人员以处理掉。尽管并不是每一次error都会引发问题,甚至大部分error都只是分布式系统中的正常现 象,但明白它们问题的原因是非常重要的。

5 测试与发布
因为是未知的系统,我们从一开始就非常注重测试。测试从一开始就分为性能测试和功能测试。性能测试主要是注意基准测试,分很多场景,比如不同混合读写比 例,不同k/v大小,不同列族数,不同命中率,是否做presharding等等。每次运行都会持续数小时以得到准确的结果。因此我们写了一套自动化系 统,从web上选择不同的场景,后台会自动将测试参数传到各台服务器上去执行。由于是测试分布式系统,因此client也必须是分布式的。
我们判断测试是否准确的依据是同一个场景跑多次,是否数据,以及运行曲线达到99%以上的重合度,这个工作非常烦琐,以至于消耗了很多时间,但后来的事实 证明它非常有意义。因为我们对它建立了100%的信任,这非常重要,比如后期我们的改进哪怕只提高2%的性能也能被准确捕捉到,又比如某次代码修改使 compact队列曲线有了一些起伏而被我们看到,从而找出了程序的bug,等等。
功能测试上则主要是接口测试和异常测试。接口测试一般作用不是很明显,因为hbase本身的单元测试己经使这部分被覆盖到了。但异常测试非常重要,我们绝 大部分bug修改都是在异常测试中发现的,这帮助我们去掉了很多生产环境中可能存在的不稳定因素,我们也提交了十几个相应的patch到社区,并受到了重 视和commit。分布式系统设计的难点和复杂度都在异常处理上,我们必须认为系统在通讯的任何时候都是不可靠的。某些难以复现的问题我们会通过查看代码 大体定位到问题以后,在代码层面强行抛出异常来复现它。事实证明这非常有用。
为了方便和快速定位问题,我们设计了一套日志收集和处理的程序,以方便地从每台服务器上抓取相应的日志并按一定规律汇总。这非常重要,避免浪费大量的时间到登录不同的服务器以寻找一个bug的线索。
由于hbase社区在不停发展,以及线上或测试环境发现的新的bug,我们需要制定一套有规律的发布模式。它既要避免频繁的发布引起的不稳定,又要避免长 期不发布导致生产版本离开发版本越来越远或是隐藏的bug爆发。我们强行规定每两周从内部trunk上release一个版本,该版本必须通过所有的测试 包括回归测试,并且在release后在一个小型的集群上24小时不受甘扰不停地运行。每个月会有一次发布,发布时采用最新release的版本,并且将 现有的集群按重要性分级发布,以确保重要应用不受新版本的潜在bug影响。事实证明自从我们引入这套发布机制后,由发布带来的不稳定因素大大下降了,并且 线上版本也能保持不落后太多。

6 改进和优化
Facebook是一家非常值得尊敬的公司,他们毫无保留地对外公布了对hbase的所有改造,并且将他们内部实际使用的版本开源到了社区。 facebook线上应用的一个重要特点是他们关闭了split,以降低split带来的风险。与facebook不同,淘宝的业务数据量相对没有如此庞 大,并且由于应用类型非常丰富,我们并们并没有要求用户强行选择关闭split,而是尽量去修改split中可能存在的bug。到目前为止,虽然我们并不 能说完全解决了这个问题,但是从0.90.2中暴露出来的诸多跟split以及宕机相关的可能引发的bug我们的测试环境上己经被修复到接近了0,也为社 区提交了10数个稳定性相关的patch,比较重要的有以下几个:
https://issues.apache.org/jira/browse/HBASE-4562
https://issues.apache.org/jira/browse/HBASE-4563
https://issues.apache.org/jira/browse/HBASE-5152
https://issues.apache.org/jira/browse/HBASE-5100
https://issues.apache.org/jira/browse/HBASE-4880
https://issues.apache.org/jira/browse/HBASE-4878
https://issues.apache.org/jira/browse/HBASE-4899
还有其它一些,我们主要将patch提交到0.92版本,社区会有commitor帮助我们backport回0.90版本。所以社区从0.90.2一直 到0.90.6一共发布了5个bugfix版本后,0.90.6版本其实己经比较稳定了。建议生产环境可以考虑这个版本。
split这是一个很重的事务,它有一个严重的问题就是会修改meta表(当然宕机恢复时也有这个问题)。如果在此期间发生异常,很有可能meta表、 rs内存、master内存以及hdfs上的文件会发生不一致,导致之后region重新分配时发生错误。其中一个错误就是有可能同一个region被两 个以上的regionserver所服务,那么就可能出现这一个region所服务的数据会随机分别写到多台rs上,读取的时候也会分别读取,导致数据丢 失。想要恢复原状,必须删除掉其中一个rs上的region,这就导致了不得不主动删掉数据,从而引发数据丢失。
前面说到慢响应的问题归纳为网络原因、gc问题、命中率以及client的反序列化问题。网络原因一般是网络不稳定引起的,不过也有可能是tcp参数设置 问题,必须保证尽量减少包的延迟,如nodelay需要设置为true等,这些问题我们通过tcpdump等一系列工具专门定位过,证明tcp参数对包的 组装确实会造成慢连接。gc要根据应用的类型来,一般在读比较多的应用中新生代不能设置得太小。命中率极大影响了响应的时间,我们会尽量将version 数设为1以增加缓存的容量,良好的balance也能帮助充分应用好每台机器的命中率。我们为此设计了表级别的balance。
由于hbase服务是单点的,即宕机一台,则该台机器所服务的数据在恢复前是无法读写的。宕机恢复速度决定了我们服务的可用率。为此主要做了几点优化。首 先是将zk的宕机发现时间尽量缩短到1分钟,其次改进了master恢复日志为并行恢复,大大提高了master恢复日志的速度,然后我们修改了 openhandler中可能出现的一些超时异常,以及死锁,去掉了日志中可能发生的open...too long等异常。原生的hbase在宕机恢复时有可能发生10几分钟甚至半小时无法重启的问题己经被修复掉了。另外,hdfs层面我们将 socket.timeout时间以及重试时间也缩短了,以降低datanode宕机引起的长时间block现象。
hbase本身读写层面的优化我们目前并没有做太多的工作,唯一打的patch是region增加时写性能严重下降的问题。因为由于hbase本身良好的 性能,我们通过大量测试找到了各种应用场景中比较优良的参数并应用于生产环境后,都基本满足需求。不过这是我们接下来的重要工作。

7 将来计划
我们目前维护着淘宝内基于社区0.90.x而定制的hbase版本。接下来除继续fix它的bug外,会维护基于0.92.x修改的版本。之所以这样,是 因为0.92.x和0.90.x的兼容性并不是非常好,而且0.92.x修改掉的代码非常多,粗略统计会超过30%。0.92中有我们非常看重的一些特 性。
· 0.92版本改进了hfile为hfileV2,v2版本的特点是将索引以及bloomfilter进行了大幅改造,以支持单个大hfile文件。现有的 HFile在文件大到一定程度时,index会占用大量的内存,并且加载文件的速度会因此下降非常多。而如果HFile不增大的话,region就无法扩 大,从而导致region数量非常多。这是我们想尽量避免的事。
· 0.92版本改进了通讯层协议,在通讯层中增加了length,这非常重要,它让我们可以写出nio的客户端,使反序列化不再成为影响client性能的地方。
· 0.92版本增加了coprocessor特性,这支持了少量想要在rs上进行count等的应用。
· 还有其它很多优化,比如改进了balance算法、改进了compact算法、改进了scan算法、compact变为CF级别、动态做ddl等等特性。
除了0.92版本外,0.94版本以及最新的trunk(0.96)也有很多不错的特性,0.94是一个性能优化版本。它做了很多革命性工作,比如去掉root表,比如HLog进行压缩,replication上支持多个slave集群,等等。
我们自己也有一些优化,比如自行实现的二级索引、backup策略等都会在内部版本上实现。
另外值得一提的是hdfs层面的优化也非常重要,hadoop-1.0.0以及cloudera-3u3的改进对hbase非常有帮助,比如本地化读、 checksum的改进、datanode的keepalive设置、namenode的HA策略等。我们有一支优秀的hdfs团队来支持我们的hdfs 层面工作,比如定位以及fix一些hdfs层面的bug,帮助提供一些hdfs上参数的建议,以及帮助实现namenode的HA等。最新的测试表 明,3u3的checksum+本地化读可以将随机读性能提升至少一倍。
我们正在做的一件有意义的事是实时监控和调整regionserver的负载,能够动态地将负载不足的集群上的服务器挪到负载较高的集群中,而整个过程对用户完全透明。
总的来说,我们的策略是尽量和社区合作,以推动hbase在整个apache生态链以及业界的发展,使其能更稳定地部署到更多的应用中去,以降低使用门槛以及使用成本。


Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of entries from March 2012 listed from newest to oldest.

February 2012 is the previous archive.

April 2012 is the next archive.

回到 首页 查看最近文章或者查看所有归档文章.