我以前一直觉得坏道什么的太难遇到了，直到去年十二月的一天，类似这样的消息在屏幕出现：

kernel: sd 4:0:0:0: [sda] Unhandled sense code
kernel: sd 4:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
kernel: sd 4:0:0:0: [sda] Sense Key : 0x3 [current]
kernel: sd 4:0:0:0: [sda] ASC=0x14 ASCQ=0x0
kernel: sd 4:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 25 42 ea af 00 00 01 00
kernel: end_request: I/O error, dev sda, sector 625142447
kernel: Buffer I/O error on device sda, logical block 78142805

这些消息会反复地出现，持续三分钟左右，在此期间做不得其他事情。这些消息出现在对磁盘执行 mount 或 fsck 之前，也就是说系统刚发现这个硬盘还没有开始挂载的时候，就会僵持三分钟。当然，等到 mount 的时候，又是一个三分钟。换句话说，光是进入 Linux 系统就需要六分多钟。神奇的是 Windows 并不会僵持住

查阅一些资料之后，排除了是内核 Bug 或者是参数设置不正确，了解到那些稀奇古怪的十六进制数字背后还有一些标准，我终于相信坏道就在眼前。实在忍受不了需要六分钟才能进入 Linux 系统，同时我也担心坏道会扩散，就在第二天去换了一个一样容量的硬盘。

最近，出于备份的需要有把这块硬盘拿出来了，那么怎么处理坏道呢？

传统的方法可能是用 badblocks 这个程序去检测一下坏道在哪里了。badblocks 有两种检查方式，一种是只读的，一种是读写的。一般想要彻底查出来坏道就要选择读写的方法，而 badblocks 在这时会依次填上 0xaa, 0×55, 0xff, 0×00，并分别读一次来确认是否有坏道。 badblocks 没有特别的优化，倘若填写 0xaa 之后检查的时候就发现需要检查的所有区域都已经坏掉了， badblocks 并不会终止检查，而是会傻傻地执行完剩下的所有检查。对于一块 320G 笔记本硬盘来说，全盘的读写检查大概需要 24 个小时。

在 badblocks 全盘读写检查的第 18 个小时，我不小心一个操作把它终止掉了 。这么漫长的操作肯定不愿意再来一次了，于是我用了一次 badblocks 全盘只读检查，结果 badblocks 说没有发现坏道 …

查阅相关资料后发现，从一开始就用不到 badblocks。现代硬盘具有自我检查机制，在一个“坏道”彻底坏掉之前的很长时间，它先是在读取的时候变得困难，而不是完全无法读取（希捷官方所言）。这时候，支持 SMART 标准的硬盘（许多年前的有硬盘就都普遍支持了）会防患于未然，把这个 sector 记录成 “Pending”，用 smartctl 命令就可以查看到 Current Pending Sector：

# smartctl -A /dev/sdb
....
... Current_Pending_Sector ... 1
....

这就表明硬盘自己发现了一个不稳定的 sector 了，这时候，如果读写这个 sector 变得正常的话，这个 sector 会被硬盘记录成正常，Current Pending Sector 会减少。如果依然发生了读取困难或者是不能读取的情况，硬盘不会做任何事情。当写入失败的时候，硬盘会自动将这个 sector 映射到它的保留区的一个好的 sector，并把这个 sector 标记成 “remapped”，由于一般坏道在真正坏掉之前还是可以读出内容的，硬盘会自动将读出来的内容复制到保留区，remap 完成之后，Current Pending Sector 也会减少，这一切都是在硬件层面上完成的，如果正常的话，普通软件（比如 badblocks）是根本没法发现这个 sector 是坏掉的，即便它去写那个 sector。

那么问题是不是就变得简单了呢，向标记为 Pending 的 sector 写一点东西就可以让硬件搞定这些问题了？看起来是的。在写之前需要知道有问题的 sector 在哪里，这个在 kernel log 里面已经看到了。现代的硬盘自己也会记录错误的 log，通过 smartctl /dev/sdb -l error 命令就能查看，虽然数量有限（我这里只有最后的 5 条），不一定会看到想要看的错误信息。

通过 fdisk 可以看到一个 sector 的大小：

# fdisk -lu /dev/sdb
 
Disk /dev/sdb: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
....

按照文章开头处 kernel log 中提到的 625142447，向这个地方写一点东西，让硬盘立即 remap 这个 Pending Sector：

# dd if=/dev/zero of=/dev/sdb bs=512 count=1 seek=625142447
dd: writing `/dev/sdb': Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 7.26951 s, 0.0 kB/s

有的朋友可能读到这里就发现我悲剧了，因为如果硬件正常的话，它会进行 remap，然后就能写成功了，但显然事与愿违，硬盘没有进行 remap，这时用 badblocks 也能发现这个坏道：

# badblocks -svw -b 512 /dev/sdb 625142447 625142447
Checking for bad blocks in read-write mode
From block 625142447 to 625142447
Testing with pattern 0xaa: done
625142447
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 1 bad blocks found.

用 smartctl 可以验证 Current Pending Sector 还是 1，并没有变成 0。一切都没有改变，所有的硬盘 SMART 自检都会失败，kernel 还是会产生那样的 log，并持续几十秒挡住你，不让用这块硬盘。

这时候我突然想到了这块希捷硬盘可能还在保修期

厂商保修信息：
    * 该商品保修期为36个月。
    * 3 年有限责任质保(第一年免费包换，第二，三年保修)

看起来只能换不能修了，早知道在刚出问题的时候就去换一个了 想到 Windows 下使用没有问题，说清楚问题所在还是挺麻烦的。并且邮寄费用并不便宜，寄来寄去说不定还会导致彻底坏掉了，还是不要修了 ….

绝望中突然看到了希望，那就是希捷硬盘可以使用的 SeaTools 。它有两个版本，Windows 版能做的事情比 smartctl 命令还要少，真的没啥用，而且把希捷自家的硬盘放到外面的盒子里就认不出来是希捷的了。不过官方说 DOS 版本能修复坏道，这应该是最后的希望了。

于是赶紧下载，刻录成光盘，由于 SeaTools for DOS 不支持移动硬盘，就把现在用的硬盘换下来，用光盘启动，见到了久违的 FreeDOS 。SeaTools for DOS 的坏道修复功能不依靠 SMART 信息，需要执行一次全盘扫描，扫描用了两个小时，接着果然提供了一个 Repair 选项，果断使用，成功了 在此之后这快硬盘用起来完全正常，即便查看 SMART 信息也看不出来有一个坏道被映射了。SeaTools for DOS 还提供了设置硬盘容量的功能，实际上这次有问题的 sector 就是整个硬盘有效 sector 的倒数第二个，修改硬盘容量，减少 1 MB，也应该是解决问题的不错办法。

总结起来，这次这个事情之后有一些经验：

1. 对于硬盘健康情况的检测，badblocks 这种东西太旧了，而且对现代硬盘也不一定有效。smartctl 可以多快好省地完成许多相关事情。
2. 虽然 SMART 是存在好多年的标准，但硬件不一定完全遵守它。厂商自己提供的工具才是最靠谱的！更广泛一点，软件和标准也是这样。
3. palimpsest 用来查看 SMART 信息和做硬盘自检很不错，如果不喜欢命令行的 smartctl 就可以用它。而 gparted 则侧重于做编辑分区的工作。
   

   用 Palimpsest 查看硬盘的 SMART 信息

4. Linux 可以早于 Windows 发现磁盘可疑坏道，可疑坏道出现后的很长一段时间内还是可以读取的，只是硬盘要多用一点力气。
5. 发现硬盘问题时应该立即换下可疑硬盘，备份数据到可靠的硬盘里，再考虑修复。除非很了解正在使用的 FS，掌握 debugfs 等的用法，否则不要直接尝试在线修复坏道。
6. 定期使用如 rsync 的软件备份数据到别的地方，硬盘数据，正如国歌中的中华民族，到了最危险的时候。
7. 有时候见到把硬盘的最后 8 MB 空出来，不分到任何分区去，也许是有一定道理的。

pacman 官方给了一个 pacman-optimize，它会把 pacman 数据库文件打包到别的地方，删除，然后再放回去。这样做可能会让这些零碎的文件在硬盘上是连续排列的，但实际效果却不是很好。

虽然用 Archlinux 应该有三年左右了，但我还从来没有看过 pacman 的数据库是什么模样。有一天终于忍不住去看了一下 /var/lib/pacman 下面到底是什么，原来是这么多零碎的小文件啊！

于是解决方案也就有了：把所谓的 pacman 数据库放到 reiserfs 文件系统里。如果你本来在这个地方用的就是 reiserfs 的话，那么不需要做任何事情， pacman 应该就很快了。如果你和我一样用的是 ext4 这样的文件系统，也不必慌张地把整个分区都换成 reiserfs。

新建一个 160 MB 的 reiserfs 文件 pacman_db.fs：

truncate pacman_db.fs --size 160M
mkfs.reiserfs -f ./pacman_db.fs

把现有的 pacman 数据库复制到这个 reiserfs 里面：

sudo mount pacman_db.fs -t reiserfs /mnt -o loop 
cp -a /var/lib/pacman/* /mnt
sudo umount /mnt

接下来修改 /etc/fstab，加上一行：

/[path_to_pacman_db]/pacman_db.fs /var/lib/pacman reiserfs defaults,loop 0 4

左边的 [path_to_pacman_db] 需要根据实际情况填一下。最右边的 4 应该是比 fstab 中其他条目大一些的数字，表示 fsck 检查时最后处理这个地方。

如果想让这个设置立即生效，执行 sudo mount /var/lib/pacman 即可。否则，重启一下就可以了。现在，使用 pacman -Syu 更新一下系统，是不是比以前快许多？

似乎扩展是很流行的样子，各种浏览器，foobar2000，谷歌拼音，WPS，都可以用扩展。

其中，有的软件成功了，令人爱不释手，比如像 Firefox，foobar2000。有的软件却没有因为扩展成功，比如谷歌拼音。或者说扩展没有给人带来好感，比如 IE 浏览器。

我觉得作为一个支持扩展的软件，最重要的就是扩展要比较有用，可以做一些事情，这一点上谷歌拼音做得就不好，由于扩展而变得比较成功的软件在这方面做得都比较好。其次，扩展要容易开发，再往后，出于安全的考虑，扩展的能力要受到约束。这两点 IE 相比 Firefox 就弱了一些，不过 Firefox 的扩展写起来还是挺麻烦的，比如其中的多国语言化就非常麻烦，对于不同的地方要使用不同的方法，总共有三种。而由于 Firefox 的灵活性，出现了 Mozilla Jetpack 和 GreaseMonkey 等，都可以让扩展写起来方便一些。

在很长的一段时间内，我觉得编写软件，技术含量是最重要的， 一个更好的算法可以带来更快的速度，或者更好的结果，当然用户体验就会好。但是现在看法有些改变，因为目前，很多东西不是需要从头做起的，除非出于学习、版权目的，或者是原先的项目代码烂到不能看而没法维护，没有必要重新实现别人已经实现的东西。大部分软件应该在乎实用性，在不违反版权的情况下，尽量使用已有的东西。

从一开始，我觉得 ibus-sogoupycc 这样一个输入法的技术含量肯定不如 sunpinyin，Linux 下的输入法用 sunpinyin 就不错了，一度怀疑是否要有将 ibus-sogoupycc 写下去的必要。但是现在，我觉得是有必要的，因为在中国大部分有网络的地方，这样一个输入法用起来是更舒服的，至少对我自己来说。

使用信号很弱的无线网，输入起来感觉也不错

出于同样的实用性的考虑，我提供了输入法扩展能力。本来我想提供一个完全兼容谷歌拼音的接口，但是后来觉得谷歌拼音的扩展接口设计得并不好，和目前输入法的无需选词流畅输入有冲突，没有遵循的必要。

开头提到的这个表情在这里： ，不难找吧。

扩展的设置应该放在用户配置文件中，目前添加一个扩展的方法是：

ime.register_command(key, modifiers, caption, script)

这里，key 和 modifiers 都是数字类型，后两者是字符串类型。

修改用户配置文件后一般要重新启动输入法才能生效，可以右击任务栏上的 ibus 图标，选择重新启动。

Hello world
下面的代码注册了一个用 Alt + H 可以激活的扩展，只要输入法被激活，无论处于中英文状态，都可以用这个热键运行这个扩展。

ime.register_command(("h"):byte(), key.MOD1_MASK, "hello", "ime.notify('hello world')")

重新启动 ibus 之后，按下方形的扩展按钮(ibus-1.2.0.20090927 版本下，方形按钮会消失，这是 ibus 的已知问题，此时通过热键仍然可以运行扩展)，可以看到一个标题为 hello 的菜单项，单击它，就可以运行扩展。

输入法扩展菜单

插入系统时间

ime.register_command(key.Shift_R, 0, "插入系统时间", "ime.commit(os.date())")

这里的 ime.commit 也是输入法提供的方法，用来直接向客户端程序输入文字，os.date 是 Lua 标准库函数。这段代码注册了一个用 右Shift 激活的插入系统时间的功能。

Lua 的标准库函数在扩展中都是可以用的，比如可以用 os.execute('mousepad &') 在后台运行一个 mousepad。

执行 Lua 代码

ime.register_command(('L'):byte(), key.SHIFT_MASK + key.MOD1_MASK ,
  "执行 Lua 代码", "ime.execute('ime.notify('..ime.get_selection()..')')")

这段代码注册了一个用 Shift + Alt + L 热键，把选中内容当做 Lua 脚本执行，并用桌面提示显示结果的扩展，这里因为有了 Shift 辅助键，所以要取大写字母 L 的 ASCII 码。其中使用方法 ime.get_selection 获得选定文字的内容，ime.execute 用来把一个字符串当做 Lua 脚本运行，双点号是字符串连接操作。

这个扩展可以比较有用，比如当选定 315+23*6145 这样的表达式之后，运行一下扩展就可以知道计算结果，也可以选定 ime.VERSION 这样的内部变量，查看其内容。甚至可以选定一段 ime.register_command 代码，动态添加扩展

“回音”效果
不知道从什么地方开始流行这种效果，我想说明的是，声明一个函数并且在扩展中调用是可以的：

function echo_effect()
	local s = ime.get_selection()
	for i = 1, #s, 3 do ime.commit((i == 1 and '' or '，')..s:sub(i)) end
end
ime.register_command(('E'):byte(), key.SHIFT_MASK + key.CONTROL_MASK,
  "产生回音", "echo_effect()")

这里简单地使用了 3 个字节 作为步长，所以只能处理纯中文。对文字 “这是回音你懂吗” 使用这个扩展会得到：”这是回音你懂吗，是回音你懂吗，回音你懂吗，音你懂吗，你懂吗，懂吗，吗”

全半角切换
输入法本身没有提供全半角切换功能，但是通过扩展可以实现类似功能：

ime.second_punc_map = {}
function toggle_punc_map()
	ime.second_punc_map, ime.punc_map = ime.punc_map, ime.second_punc_map
	ime.apply_settings()
	ime.notify('已切换到' .. (ime.punc_map['.'] and '全' or '半') ..'角')
end
ime.register_command((','):byte(), key.CONTROL_MASK , "全半角切换", "toggle_punc_map()")

注册了 Ctrl + 逗号 作为切换热键，并会用桌面提示显示切换结果。

全双拼切换
可以仿造上例写出：

ime.register_command(0, 0, "全双拼切换",
  "ime.use_double_pinyin = not ime.use_double_pinyin ime.apply_settings()")

前面填写的两个 0 表示这个扩展没有热键，你也可以再加上一句 ime.notify，使得切换的时候有桌面提示。

对缓存的操作
缓存是存在全局的 request_cache 中的，可以直接对其操作：

function show_request_cache()
	for i,v in pairs(request_cache) do
		ime.commit('"'..i..'" => "'..v..'"\n')
	end
end
ime.register_command(0, 0 , "查看缓存", "show_request_cache()")
ime.register_command(0, 0 , "清空缓存", "request_cache = {}")

其中的 ime.commit 方法用来向客户端插入文本，还有一个方法是 ime.request，用来向输入法提交一个拼音请求，比如下面这段代码片段将向输入法提交《春晓》的拼音：

for _, v in pairs
{'chun mian bu jue xiao', 'chu chu wen ti niao',
 'ye lai feng yu sheng', 'hua luo zhi duo shao'} do
	ime.request(v)
	ime.commit('\n')
end

给自己发送飞信
输入法全局配置文件默认加载了 socket.http 和 socket.url 模块，可以用它们来访问网络。

比如，下面的代码通过 api.bz 这个在线接口把选定文字内容通过飞信发送给自己：

function send_sms(content)
	http.TIMEOUT = 2
	local res = http.request('https://sms.api.bz/fetion.php?username=15566119320&password=nevermind&sendto=15566119320&message='..url.escape(content))
	ime.notify(res or '飞信发送失败', content, 'info')
end
 
ime.register_command(('m'):byte(), key.CONTROL_MASK + key.MOD1_MASK, "飞信发送", "send_sms(ime.get_selection())")

以上填写的飞信用户名和密码皆为虚构，实际用的时候需要改一下。

简繁体转换和翻译
使用 Google API 来翻译文字，从简体中文翻译成繁体中文就实现了转换成繁体

function google_translate(text, langpair)
	local url = 'http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q='..url.escape(text)..'&langpair='..url.escape(langpair)
	http.TIMEOUT = 1
	local res = http.request(url)
	if res then res = res:match('"translatedText":"(.-)"}') end
	return tostring(res or text)
end
 
ime.register_command(('t'):byte(), key.CONTROL_MASK + key.MOD1_MASK ,
  "转换成繁体", "ime.commit(google_translate(ime.get_selection(), 'zh-CN|zh-TW'))")
ime.register_command(('e'):byte(), key.CONTROL_MASK + key.MOD1_MASK ,
  "翻译成英文", "ime.commit(google_translate(ime.get_selection(), 'zh-CN|en'))")

写在最后

这是一个悲剧。

Lua 作者根本不相信多线程，原因是现在的主流语言中连 a = a + 1 都不是原子的，谈什么多线程呢？

我曾经做过一些尝试，确实让程序多线程地执行 Lua 代码，又共享一些全局数据，不是轻松的事情。我也想到一些解决办法，但是都太麻烦了，于是就偷懒不管那么多了。

这有什么影响呢？影响就是目前输入法执行 Lua 代码是单线程的，扩展中的 Lua 代码会造成阻塞。在有网络请求等操作的时候，要注意控制超时，否则程序可能被认为没有响应了，各种死法都有可能出现

目前输入法的自由程度到了可以随意 AOE，比如用 os.execute('pkill Xorg')，就可以干掉许多无辜者。正所谓权力越大，责任越大。到底安全与否，就看扩展中的代码自我约束得如何了

我这样做已经有一段时间了，除了Windows会发现硬件改变要求重新激活之外，还没有发现问题 :-) 但是周围的同学似乎觉得这样做比较麻烦，很有风险，或者无从下手。其实比较简单也没有这么可怕啦，下面普及一下：

首先要创建一个特殊的虚拟磁盘文件，指向真实磁盘的某个分区，这可以参考VirtualBox用户手册中的9.10章节。简单来说：

注：由于这些命令需要/dev/sda的读写权限，以后虚拟机在使用这些vmdk文件的时候，也需要这样的权限，建议把当前用户加在disk组里解决问题：gpasswd disk -a `whoami`

# 把整个sda映射出去
VBoxManage internalcommands createrawvmdk -filename /path/to/sda.vmdk -rawdisk /dev/sda
# 或者，处于安全考虑，只允许sda1和sda5在虚拟机里用到，虚拟机里仍然可以知道有其他分区存在，但是不能读写
VBoxManage internalcommands createrawvmdk -filename /path/to/sda1_and_sda5.vmdk -rawdisk /dev/sda -partitions 1,5 -relative

这里的relative参数保证了创建出来的虚拟磁盘文件的可移植性，在sda1或者sda5的实际位置和大小变化后也可以用，没有这个参数的话到时候就要重新创建一遍vmdk文件了。
创建好可能会产生多个文件：a.vmdk和a-pt.vmdk，实际在虚拟机里使用前一个文件，后一个需要存在。

这样就基本完成啦，不过如果你打开这样配置的虚拟机后就会发现一个问题，MBR在这种默认情况下是和真实硬盘相同的，GRUB是和主机相同的，如果GRUB配置文件所在分区虚拟机没有访问权限的话，就会引导不能

当然，虚拟机里的MBR可以设置得和主机不一样，不过操作起来比较麻烦，据说也有一定的危险。安全的做法是使用携带特定配置文件的GRUB的Live CD镜像来引导，下面就开始做这样一张CD镜像（适用于GRUB 1.0）：

# 准备一个目录
mkdir -p iso/boot/grub
# 复制必要文件
cp /usr/lib/grub/*-pc/stage2_eltorito /boot/grub/menu.lst iso/boot/grub
# 编辑复制过来的 menu.lst ，去掉其中的 savedefault ，...
vim iso/boot/grub/menu.lst
# 创建iso
mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o grub-custom.iso iso

在虚拟机里设置使用这张iso引导之后，就大功告成啦～