苦水潭

之前讨论影响硬盘寿命的 load/unload 的问题（见 旧文一 、 旧文二 ），都是集中于对 haprm -B 参数的调整。而这次要提醒大家注意的，是 hdparm -S 参数。 这里是 man hdparm 的 -S 部分的说明。 Set the standby (spindown) timeout for the drive. This value is used by the drive to deter‐mine how long to wait (with no disk activity) before turning off the spindle motor to save power. Under such circumstances, the drive may take as long as 30 seconds to respond to a subsequent disk access, though most drives are much quicker. The encoding of the timeout value is somewhat peculiar. A value of zero means "timeouts are disabled": the device will not automatically enter standby mode. Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the...

下午大部分时间都在调一段 c++ 代码。某线程共享 vector，用于存放对象的指针。创建对象之前先要检查一下是否已经存在符合某条件的对象，有则取消创建。对象创建时指针进入 vector，对象销毁时指针从 vector 中删除。 逻辑虽然简单，但是因为需要线程安全，所以加锁解锁也是步步小心。 但是跑起来之后还是出了问题。有时候明明 vector 应该已经空了，检查函数竟然返回存在的结果，导致某该被创建的对象创建失败。 根据日志输出，进行这个对象的创建前检查正巧位于某线程将某对象刚刚从 vector 中删除的时候，而检查出已存在的结果恰好是那个刚刚被删掉的指针，于是本能的怀疑是线程同步出了问题。 集中精神，走查代码（注意力都在加解锁上，这个过程耗时比较长）。一无所获。无奈，在日志输出中将每次 vector 操作时 vector 的状态进行了详细输出 。 令人瞠目的一幕出现了，vector 的 size 居然就从没有减少过！ 赶紧检查 destructor，是这样写的： ... LockMutex(...) remove(foo_vector.begin(), foo_vector.end(), this); UnlockMutex(...) ... 如果你也看不出不对，那么恭喜，你的 c++ 水平和我一样不济。不用多解释，看 文档 ，好好补习一下 remove 到底是怎么用的。这个地方用 remove 其实并不合适。 将上述代码改成如下形式，问题解决。 ... LockMutex(...) vector ::iterator it=find(foo_vector.begin(), foo_vector.end(), this); if (it != foo_vector.end()) foo_vector.erase(it); UnlockMutex(...) ... 感受： 1、此例跟多线程一点关系也没有。“程序员的第一直觉几乎总是错的”说的就是这个。 2、“用非母语交谈，思维易受干扰”，用不熟悉的语言编程，也是一样。 3、不折不扣的 printf debug 流。 4、c++ 还是半吊子。

我这个新笔记本（Fujitsu MG75X/V）从打买回来装 linux，就没发现过怎么调节背光，无论是 Ubuntu 还是 ArchLinux。 不过一直以来我倒也不以为意。像我这种每天要盯着屏幕超过 8 个小时的人，通常屏幕亮度都比较低，而且不需要频繁的调节。屏幕亮度在某次设置 bios 时候调好了之后，就一直没有动过。 说来惭愧，要不是看到 这篇帖子 ，估计我就会这么一直放任下去。 调节背光亮度，说来简单，就是一行命令的事。 xrandr --output LVDS --set BACKLIGHT [value] 至于这个 [value] 取多少合适，可以用以下命令来查一下。 xrandr --prop 关于背光的控制方式，可以 man intel 来仔细查看（之前也看到过关于背光调节的部分，但是因为当时没有找到可操作的办法——以为是折腾 xorg.conf 呢，没想到是 xrandr——所以一直没有引起注意）。在我的本上只有 legacy 模式起作用。在 legacy 模式下，value 的范围是 0～255。我常用的亮度值是 49。 既然有了调节背光的手段，一时兴起想把 Fn+F6/F7 两个背光调节键的问题也一并解决。照 ArchLinux Wiki 上的 这篇文章 简单试了一下，Fn+F6/F7 连 scancode 都打印不出来，“the key is not seen in any way by our os, we whould give up”。想来也是个很麻烦的事情，暂且搁置吧。2.6.25 内核眼看着也该发布了（已经 rc9 了，不远矣不远矣），或许新内核能直接带来些许惊喜也说不定。

4 月 11 日夜，云来势汹汹，遮天蔽月，席卷半穹。大图见我 相册 。

4 月 10 日，零点。准备关机。Win2k3 std。 例行转移一些大个文件到外置存储设备。漫长的拷贝进行中。 这时提示 7 个安全补丁已经下载完毕。照惯例点了安装。 装到第 6 个，惊奇的发现桌面失去响应。硬盘繁忙，看不出在忙什么。Ctrl + Alt + Del，呼叫任务管理器，未果。 等了几分钟，依旧。 无奈，reset。虚惊正式拉开序幕。 画面定格在了 Win2k3 的欢迎页。硬盘有节奏的工作。（莫非硬盘……） reset，F8，最后一次正确配置，同上。 reset，F8，带网络的安全模式。硬盘哗啦哗啦，等了一阵之后居然自动重启。 F8，安全模式，硬盘很是卖力的哗啦了一阵之后居然又是重启。（看来真的是……） 0:10 了。准备放弃尝试，洗漱去了。 回来之后，惊奇的发现居然进入登录界面了。伴随几个消息框，Windows 延缓写入失败云云，写入位置有 $MFT 和 $BitMap 等等。看起来挺诡异，确也不难找先例： http://zhidao.baidu.com/question/46112939.html http://topic.csdn.net/t/20050813/12/4206875.html 登入。硬盘狂转，慢如蜗牛。重新安装 7 个安全补丁。安排所有分区自检。重启。 漫长的自检。某几个分区修复错误若干云云。自动重启。 居然又是自检。然后居然顺利进入登录界面。 登入，一切复原。 检查之前转移的大文件，已经成功转移了。看表，0:18，睡觉。 感想： 1、硬盘好样的，西数比日立坚挺。 2、安装补丁的时候那句“请关掉其他所有正在运行的应用程序”不是白写的，Windows 真难伺候。 3、NTFS 的自检修复还是靠谱的。