关于作者

用户名:Junvz
笔名:Julian
地区: 北京-海淀
行业:其他

日历  

快速登录

+ 用户名:
+ 密 码:

在线留言



信息安全

博客链接

软件相关

手册文档

音乐相关

媒体推荐

访问统计:
文章个数:99
评论个数:43
留言条数:5




Powered by BlogDriver 2.1

爱与理想

 

MSN Online Status Indicator

强极则辱 情深不寿 谦谦君子 温润如玉

文章

php extensions development

- 作者: Julian 2005年09月26日, 星期一 10:26  回复(1) |  引用(0) 加入博采

行家解疑:BT下载到底伤不伤硬盘 [转帖]
编者按:
很多朋友喜欢用BT下载,但是却听人说使用BT下载容易伤硬盘,缩短硬盘寿命,那么,BT下载是否如大家所说会伤硬盘呢,下文将为你揭开这个谜底……
 
  为什么频繁读写会损坏硬盘呢?

  磁头寿命是有限的,频繁的读写会加快磁头臂及磁头电机的磨损,频繁的读写磁盘某个区域更会使该区温度升高,将影响该区磁介质的稳定性还会导至读写错误,高温还会使该区因热膨涨而使磁头和碟面更近了(正常情况下磁头和碟面只有几个微米,更近还得了?),而且也会影响薄膜式磁头的数据读取灵敏度,会使晶体振荡器的时钟主频发生改变,还会造成硬盘电路元件失灵。

  任务繁多也会导至IDE硬盘过早损坏,由于IDE硬盘自身的不足,,过多任务请求是会使寻道失败率上升导至磁头频繁复位(复位就是磁头回复到 0磁道,以便重新寻道)加速磁头臂及磁头电机磨损。

  先说一下现代硬盘的工作原理

  现在的硬盘,无论是IDE还是SCSI,采用的都是"温彻思特"技术,都有以下特点:1。磁头,盘片及运动机构密封。2。固定并高速旋转的镀磁盘片表面平整光滑。3。磁头沿盘片径向移动。4。磁头对盘片接触式启停,但工作时呈飞行状态不与盘片直接接触。

  盘片: 硬盘盘片是将磁粉附着在铝合金(新材料也有用玻璃)圆盘片的表面上.这些磁粉被划分成称为磁道的若干个同心圆,在每个同心圆的磁道上就好像有无数的任意排列的小磁铁,它们分别代表着0和1的状态。当这些小磁铁受到来自磁头的磁力影响时,其排列的方向会随之改变。利用磁头的磁力控制指定的一些小磁铁方向,使每个小磁铁都可以用来储存信息。

  盘体: 硬盘的盘体由多个盘片组成,这些盘片重叠在一起放在一个密封的盒中,它们在主轴电机的带动下以很高的速度旋转,其每分钟转速达3600,4500, 5400 ,7200甚至以上。

  磁头: 硬盘的磁头用来读取或者修改盘片上磁性物质的状态,一般说来,每一个磁面都会有一个磁头,从最上面开始,从0开始编号。磁头在停止工作时,与磁盘是接触的,但是在工作时呈飞行状态。磁头采取在盘片的着陆区接触式启停的方式,着陆区不存放任何数据,磁头在此区域启停,不存在损伤任何数据的问题。读取数据时,盘片高速旋转,由于对磁头运动采取了精巧的空气动力学设计,此时磁头处于离盘面数据区0.2---0.5微米高度的"飞行状态"。既不与盘面接触造成磨损,又能可靠的读取数据。

  电机: 硬盘内的电机都为无刷电机,在高速轴承支撑下机械磨损很小,可以长时间连续工作。高速旋转的盘体产生了明显的陀螺效应,所以工作中的硬盘不宜运动,否则将加重轴承的工作负荷。硬盘磁头的寻道饲服电机多采用音圈式旋转或者直线运动步进电机,在饲服跟踪的调节下精确地跟踪盘片的磁道,所以在硬盘工作时不要有冲击碰撞,搬动时要小心轻放。

  原理说到这里,大家都明白了吧?

  首先,磁头和数据区是不会有接触的,所以不存在磨损的问题。

  其次,一开机硬盘就处于旋转状态,主轴电机的旋转可以达到4500或者7200转每分钟,这和你是否使用 FLASHGET 或者ED都没有关系,只要一通电,它们就在转.它们的磨损也和软件无关。

  再次,寻道电机控制下的磁头的运动,是左右来回移动的,而且幅度很小, 从盘片的最内层(着陆区)启动,慢慢移动到最外层,再慢慢移动回来,一个磁道再到另一个磁道来寻找数据。不会有什么大规模跳跃的(又不是青蛙)。所以它的磨损也是可以忽略不记的。

 那么, 热量是怎么来的呢 ?

  首先是主轴电机和寻道饲服电机的旋转,硬盘的温度主要是因为这个。

  其次,高速旋转的盘体和空气之间的摩擦。这个也是主要因素。而硬盘的读写?很遗憾,它的发热量可以忽略不记!

  硬盘的读操作,是盘片上磁场的变化影响到磁头的电阻值,这个过程中盘片不会发热,磁头倒是因为电流发生变化,所以会有一点热量产生。写操作呢?正好反过来,通过磁头的电流强度不断发生变化,影响到盘片上的磁场,这一过程因为用到电磁感应,所以磁头发热量较大。但是盘片本身是不会发热的,因为盘片上的永磁体是冷性的,不会因为磁场变化而发热。

  但是总的来说,磁头的发热量和前面两个比起来,是小巫见大巫了。热量是可以辐射传导的,那么高热量对盘片上的永磁体会不会有伤害呢?其实伤害是很小的,永磁体消磁的温度,远远高于硬盘正常情况下产生的温度。当然,要是你的机箱散热不好,那可就怪不了别人了。

  不得不说一下某人的几个错误:

  一、高温是影响到磁头的电阻感应灵敏度,所以才会产生读写错误,和永磁体没有关系。

  二、所谓的热膨胀,不会拉近盘体和磁头的距离,因为磁头的飞行是空气动力学原理,在正常情况下始终和盘片保持一定距离。当然要是你大力打击硬盘,那么这个震动。。。。。

  三、所谓寻道是指硬盘从初使位置移动到指定磁道。所谓的复位动作,并不是经常发生的。因为磁道的物理位置是存放在CMOS里面,硬盘并不需要移动回0磁道再重新出发。只要磁头一启动,所谓的复位动作就完成了,除非你重新启动电脑,不然复位动作就不会再发生。

  四、IDE硬盘和SCSI硬盘的盘体结构是差不多的。只是SCSI硬盘的接口带宽比同时代的IDE硬盘要大,而且往往SCSI卡往往都会有一个类似CPU的东西来减缓主CPU的占用率。仅此而已,所以希捷才会把它的SCSI硬盘的技术用在IDE硬盘上。

  五、硬盘的读写是以柱面的扇区为单位的。柱面也就是整个盘体中所有磁面的半径相同的同心磁道,而把每个磁道划分为若干个区就是所谓的扇区了。硬盘的写操作,是先写满一个扇区,再写同一柱面的下一个扇区的,在一个柱面完全写满前,磁头是不会移动到别的磁道上的。所以文件在硬盘上的存储,并不是像一般人的认为,是连续存放在一起的(从使用者来看是一起,但是从操作系统底层来看,其存放不是连续的)。所以FLASHGET或者ED开了再多的线程,磁头的寻道一般都不会比你一边玩游戏一边听歌大。当然,这种情况只是单纯的下载或者上传而已,但是其实在这个过程中,谁能保证自己不会启动其它需要读写硬盘的软件? 可能很多人都喜欢一边下载一边玩游戏或者听歌吧?更不用说WINDOWS本身就需要频繁读写虚拟内存文件了。所以,用FG下载也好,ED也好,对硬盘的折磨和平时相比不会太厉害的。

 六、再说说FLASHGET为什么开太多线程会不好和ED为什么硬盘读写频繁。首先,线程一多,cpu的占用率就高,换页动作也就频繁,从而虚拟内存读写频繁,至于为什么,学过操作系统原理的应该都知道,我这里就不说了。ED呢?同时从几个人那里下载一个文件,还有几个人同时在下载你的文件,这和FG开多线程是类似的。所以硬盘灯猛闪。但是,现在的硬盘是有缓存的,数据不是马上就写到硬盘上,而是先存放在缓存里面,,然后到一定量了再一次性写入硬盘。在FG里面再怎么设置都好,其实是先写到缓存里面的。但是这个过程也是需要CPU干预的,所以设置时间太短,CPU占用率也高,所以硬盘灯也还是猛闪的,因为虚拟文件在读写。

  七、硬盘读写频繁,磁头臂在寻道伺服电机的驱动下移动频繁,但是对机械来说这点耗损虽有,其实不大。除非你的硬盘本身就有机械故障比如力臂变形之类的 (水货最常见的故障)。真正耗损在于磁头,不断变化的电流会造成它的老化,但是和它的寿命相比……应该也是在合理范围内的。除非因为震动,磁头撞击到了盘体。

  八、受高温影响的最严重的是机械的电路,特别是硬盘外面的那块电路板,上面的集成块在高温下会加速老化的。所以IBM的某款玻璃硬盘,虽然有坏道,但是一用某个软件,马上就不见了。再严重点的,换块线路板,也就正常了。就是这个原因。

  总之,硬盘会因为环境不好和保养不当而影响寿命,但是这绝对不是软件的错。FLASHGET也好,ED也好,FTP也好,它们虽然对硬盘的读写频繁, 但是还不至于比你一般玩游戏一般听歌对硬盘伤害大.说得更加明白的话,它们对硬盘的所谓耗损,其实可以忽略不记.不要因为看见硬盘灯猛闪,就在那里瞎担心.不然那些提供WEB服务和FTP服务的服务器,它们的硬盘读写之大,可绝非平常玩游戏,下软件的硬盘可比的。

  硬盘有一个参数叫做连续无故障时间。它是指硬盘从开始运行到出现故障的最长时间,单位是小时,英文简写是MTBF。一般硬盘的MTBF至少在 30000或40000小时。具体情况可以看硬盘厂商的参数说明。这个连续无故障时间,大家可以自己除一下,看看是多少年。然后大家自己想想,自己的硬盘平时连续工作最久是多长时间。

  目前我使用的机器,已经连续开机1年了,除了中途有几次关机十几分钟来清理灰尘外,从来没有停过(使用金转6代40G)。另外还有三台使用SCSI硬盘的服务器,是连续两年没有停过了,硬盘的发热量绝非平常IDE硬盘可比(1万转的硬盘啊)。在这方面,我想我是有发言权的。

  最后补充一下若干点:

  一、硬盘最好不要买水货或者返修货。水货在运输过程中是非常不安全的,虽然从表面上看来似乎无损伤,但是有可能在运输过程中因为各种因素而对机械体造成损伤。返修货就更加不用说了。老实说,那些埋怨硬盘容易损坏的人,你们应该自己先看看,自己的硬盘是否就是这些货色。

  二、硬盘的工作环境是需要整洁的,特别是注意不要在频繁断电和灰尘很多的环境下使用硬盘。机箱要每隔一两个月清理一下灰尘。

  三、硬盘的机械最怕震动和高温。所以环境要好,特别是机箱要牢固,以免共震太大。电脑桌也不要摇摇晃晃的。

  四、要经常整理硬盘碎片。这里有一个大多数人的误解,一般人都以为硬盘碎片会加大硬盘耗损,其实不是这样的。硬盘碎片的增多本身只是会让硬盘读写所花时间比碎片少的时候多而已,对硬盘的耗损是可以忽略的(我在这里只说一个事实,目前网络上的服务器,它们用得最多的操作系统是UNIX,但是在UNIX下面是没有磁盘碎片整理软件的。就连微软的NT4,本身也是没有的)。不过,因为磁头频繁的移动,造成读写时间的加大,所以CPU的换页动作也就频繁了,而造成虚拟文件(在这里其实准确的说法是换页文件)读写频繁,从而加重硬盘磁头寻道的负荷。这才是硬盘碎片的坏处。

  五、在硬盘读写时尽量避免忽然断电,冷启动和做其他加重CPU负荷的事情(比如在玩游戏时听歌,或者在下载时玩大型3D游戏),这些对硬盘的伤害比一般人想象中还要大。

  总之,只要平常注意使用硬盘,硬盘是不会那么快就和我们说BYEBYE的。当然,如果是硬盘本身的质量就不行,那我就无话可说了。

- 作者: Julian 2005年09月18日, 星期日 12:39  回复(1) |  引用(1) 加入博采

ThinkPad T4x清洁

 

- 作者: Julian 2005年09月6日, 星期二 00:18  回复(0) |  引用(0) 加入博采

qmail学习笔记

References


- 作者: Julian 2005年09月2日, 星期五 14:22  回复(0) |  引用(0) 加入博采

MAC学习笔记

Setup:

Firstly, MAC Framework must be built into the kernel with adding one line into the kernel configuration file:" option MAC".


When MAC Framework is built into the kernel, administrator can choose which security policy modules shoud be loaded. There are such MAC modules: mac_portacl, mac_ifoff, mac_biba, mac_bsdextended, mac_mls, which are loaded for the different demand. Unlike MAC Framework, these modules need not to be built into the kernel, which are able to loaded by updating some boot options into loader.conf.

Inplementation:

* Components of MAC Framework
six logical components
reference: 7.1

* Framwork startup

* Policy Registration
Modules are distinguished from policies: kernel modules may contain a number of code objects.

* Entry Point Invocation, Composition
Three kind of entry points:
1. MAC_PERFORM: no return value, is used to post an event to interested policies.
2. MAC_CHECK: used to an access control entry point or an entry point supporting detecting and classification of failure modes. a function named 'error_select' can encode an ordering of various failure classes.
3. MAC_BOOLEAN: implements a call-out to decision function, and composes the return values using an arbitrary boolean operator.

* Access Control Entry Point
'error_select' will select one of the errors based on precedence if a check fails.
reference: 7.5

* Label Management
A number of access control policies rely on security labels maintained on objects for the purpose of performing access control decisions, and various labels contain the different contents from each other.

There are several kinds of labeled objects ( Figure 4. Labeled objects ), and each such structure holds one or more instances of a policy-agnostic label structre for per-policy data: each policy reserving label state is allocated a slot in the label structure, and each slot holds either a void pointer and an integer.

Labels are initialized, allocated and destroyed along with their objects.
The kernel distinguishes two types of object allocation: permit blocking and not tolerate blocking.
Label association and creation.

* Pre-Object Behavior
Association and creation events depend on the availability of context.
MAC Framework-maintained labels must be protected against unsynchronized parallel access by means of locking primitives and access protocols.
A native locking protection: objects to protect the corrosponding labels.

* Process Credentials
Process credential structures contain identity and authorization
information associated with the UNIX security model. The credential
label was protected by an 'immutable once shared' policy, which may
be changed only while one reference exists, such as immediately after
creation.

* VFS Objects
VFS object, exposed via /dev.
1. Single-label: derived from the FS mountpoint by the framework. labels may not be modified.
2. Multi-label: responsible for it.

Summary:

有不对的地方请指正~

内核框架设计

  • %内核设计的要求是:
    %1. 实现一个模块化的框架,提供通用的策略平台(标签)
    %2. 增加重要安全决策的能力
    %3. 未来的模块可以很容易的兼容
  • %应用程序设计的要求:
    %1. 允许与策略独立的安全应用程序,而不仅仅是策略安全程序,可以应用于系统
    %2. 可以从框架输出相关信息,以便监视策略以及通用管理项。
  • % 策略独立(policy-independent)的意思是,这些应用程序不需要理解具体的策略和标签含义,
    % 它们使用的时候只是通过一个mac_check函数来使用标签。比如"ls -lZ",当修改策略或标签的时候对它的返回结果并没有影响。
    % 策略相关(policy-aware)的意思是,这些应用程序并不一定以系统用户的身份执行,或者它们要执行与特定策略相关的应用,比如数据库、邮件服务器之类。该应用程序就是与Biba或者mls挂钩的当修改了策略,该应用程序会受到影响。

内核框架实现

  • % MAC框架管理有三种接口:sysctl, loader.conf, system calls
  • % 内核服务结合MAC框架有两种方式:
    %1、调用API;
    % 2、提供一个与策略无关的(policy-agnostic)的标签结构指针,指向安全相关的对象。这些指针由MAC框架通过标签管理入口点(lable management entry point)维护,并且允许框架对策略模块提供一种标签服务,使得可以对维护这些安全对象的内核子系统作无关入侵(non-invasive)的修改。
    ——例如,指针可以指向process credentials, sockets, pipes, vnodes, Mbufs, network interfaces等等安全相关的对象。
  • % MAC框架在启动的早期初始化,紧接在内核内存分配、终端启动和锁机制启动之后,但在高层设备检测和其他内核与用户进程启动之前模块载入同时相应的策略就注册了。策略有一个load-time flag,表明是否可以在启动后载入(loader.conf)或载出,策略注册由busy count和lock保持同步和互斥,不允许两个进程同时修改策略列表
  • % 静态入口(static entry)就是在系统启动之前载入,但不能再载出的策略
  • % 策略的同步一般都是使用BSD中已有的互斥机制,同步原语。
    Note: 当写入策略使用同步原语时,需要小心——需要注意已存在的内核锁顺序——有些入口点是不允许睡眠的。
    当策略模块调用其他内核子系统时,需要释放in-policy locks,避免死锁。
    模块将维持一个锁的树,以避免死锁。
  • % 一共三种策略入口点:
    % 1. 无返回值,一般用于传送事件消息到相关策略,事件内容有可能是修改该策略,标签管理之类
    % 2. 有返回值,一般用于访问控制,会返回每个策略结果,或组合结果到变量errno,返回错误值被error_select选择,按优先级选取其中一个,再送给内核服务(kernel services)。
    % 3. 返回布尔值,一般用于某些特定情况,策略增加某已存在内核服务决策,而不是要得到访问控制的结果
  • % 用于登记标签存储的策略被分配给一个"solt??"标识,它被用于撤销标签存储。
    % 存储方式完全受策略模块控制:模块由一些与内核对象生命周期相关的入口点来提供
    % ——包括initialization, association/creation, and destruction。
    % 使用这些接口,有可能执行引用计数和其他存储模块。直接存取对象结构的话,
    % 一般不需要模块再去取标签(?),而是像MAC框架那样通过一个指向对象的指针和指向标签的指针来获得。
    % 一大例外是process credential(?),但这应该会在未来的MAC版本中改正过来。
  • % Association: 当对象已经存在,它的标签已经初始化时
    % Creation: 当绑定一个内核对象结构到一个全新的对象实例时候

策略设计与实现

  • % FreeBSD 5.0 includes a number of kernel modules that provide a diverse set of kernel access control extension.
    % Extensions are also available from third parties.
    %FreeBSD 5.0 内置一些策略模块提供各种不同的内核访问控制扩展,它是开放的,允许第三方的策略模块。
  • % Biba是一个固定标签策略,对主体客体的标签改变都是确定明显的
    % Lomac是一个浮动标签策略,它跟Biba类似,但它允许高级客体(process)任意访问低级对象(files),
    % 但是将会降低该客体的完整性级别,从而阻止完整性规则被破坏
  • % 客体标签包括三部分:标签种类,活动标签和可用标签集。
    % 集合用两个有序的Biba标签元素表示,设置在进程上,
    % 允许进程可以改变自己的活动标签的完整性值到比该范围最低点更高或者无关的完整性值,
    %         或者改变自己的活动标签的完整性值到比该范围最高点更低或者无关的完整性值。

Slide download:

Reference:

  • Robert Watson, Brian Feldman, Adam Migus, Chris Vance, Design and Implementation of the TrustedBSD MAC Framework.
  • FreeBSD Architecture HandBook

- 作者: Julian 2005年08月24日, 星期三 14:34  回复(0) |  引用(0) 加入博采