在文件系统选型后,贝壳骤然发现用ext3保存媒体文件是一件很傻的事情。耗费空间多,性能差,安全性低。根据文章结论,其实最好的文件系统是xfs。同时,贝壳的mini-itx空间基本满了(/home分区75-80%)。所以,贝壳准备买一块新的硬盘,然后将数据迁移过去。

硬件选择上,贝壳询问了熟悉的硬件商。他说日立没货,WD的盘问题比较多,推荐希捷的。而且只有绿盘,具体型号是ST2000DL003-9VT166,SataIII,常规转速5900。ST的2T盘入手后,贝壳做了一下基础测试,hdparm分数是,原本的WD硬盘90M/s,新的ST硬盘70M/s,公司的硬盘99M/s。看来硬盘性能还是WD的比较好一点,当然,也可能是因为新硬盘本身就是低档硬盘。

贝壳的第一选择,是按照原本的U盘安装设置,安装debian系统。不过前后两次都可耻的失败了,主要原因是mini-itx对U盘启动的支持并不是很好。被迫,用新买的大型电脑安装,又失败。原因是6.0的安装镜像对boot.img.gz方式的U盘启动支持不良。算了,先装5.0升级。没想到,这个原因直接导致了贝壳两次系统安装完毕后无法引导升级。为什么?因为硬盘的尺寸刚刚好比2T大了点。gurb升级到grub2的时候,为了让你支持全部空间,很好心的帮你升级到了gpt。然而gpt需要一个分区来保存一些信息,新多出来的空间又刚好不足以保存这个数据。因此,grub-pc就升级失败,而且救都没法救——因为没空间了。

两次折腾下来,贝壳基本搞明白了为什么。然而要解决这个问题,就要手工分区,计算大小,产生lvm,设定,然后debootstrap,再设定。或者就直接使用debian

6.0的安装镜像。这个时候,悲崔的事情来了——U盘安装那篇文章的上一节,就说明了如何直接使用usb启动iso,直接cat iso > /dev/sdX就可以了。早知道这么简单,何必折腾那么一大套呢,哎。

debian 6.0的安装系统比5.0的好了很多,磁盘分区支持gpt,直接就生成了bios_grub分区。lvm2的支持增加了vg级别的控制,而不仅仅只能控制lv的生成和删除。同时增加了软raid的支持。这就很好的解决了贝壳当前的问题。

贝壳的分区方案是,gpt分区表,一个bios_grub分区,一个ext2的boot分区,一个lvm分区。lvm上面分8G的root,ext4格式。4G的swap,可以适应当前内存和升级到4G的内存(linux swap推荐是,4G以下两倍于内存,4G以上和内存一致)。1.7T的home,xfs格式。剩余268G。为什么要剩余?因为xfs只能扩展不能缩小,如果我需要扩展root和swap,或者需要产生新的lv来做虚拟机,不留下一定空间会出问题的。如果home不足,我再扩展150G基本可以解决问题。

分区和安装都很顺利,然而approx对新的系统基本没有缓冲作用。我略微想了一下,大概明白了为什么——原有系统是用i386架构和amd64内核,而新系统则是架构内核都是amd64。或者通俗来说,原系统是64位内核下的32位混合系统,而新系统是彻底的64位系统。32位的包对64位的系统一点用都没有,所以approx原有的包都白缓存了。

好吧,瑕不掩瑜,这次升级基本还是成功的。安装对应软件包,复制数据(推荐首次cp -a,速度快,后面用rsync保证同步),修改属主(否则很多程序无法启动)。尤其需要注意,mldonkey在downloads.ini中,不但保存了以哪个用户启动,同时也保存了用户id。新系统中用户名和id对应关系会发生变化,因此要修改正确。基本——事情就完了。

一个小细节是,uwsgi由于amd64升级,所以无法使用。贝壳解决了一下问题,重新编译这个包。另外,debian官方的包出来了,目前处于sid状态,大家可以等着什么时候进入testing状态了。