分类归档: OpenSource

恢复 EXT3 Superblock 的正确方法

前几天遇到一个 Linux Ext3 文件系统超级块(Superblock)错误问题.

.... bad superblock on /dev/hda4

一个同事做的恢复, 结果把数据都抹掉了. 后来想想, 当时的直接 fsck 的恢复方法不对. 正确的方法应该是这样的:
1 获取错误的出错磁盘(或者设备)块的大小.
有很多种方法可以得到. 比如,

# tune2fs -l /dev/hda4

其实大多数情况下是 1 K.
2 对当前的出错磁盘备份.
恢复超级块(Superblock)的过程其实也是一个有风险的过程.能做备份就做好备份. 如果有其他空闲设备, 用 dd 命令把该设备上的内容备份起来.
3 一般来说, 超级块错基本上也就是主超级块错, 在 Ext2/Ext3 文件系统创建的时候, 会同时在屏幕上提示我们在已经在几个地方备份了超级块.那么怎么发现这些超级块在什么地方呢? 我们看看帮助信息:

-b superblock
Instead of using the normal superblock, use an alternative
superblock specified by superblock. This option is normally
used when the primary superblock has been corrupted. The loca-
tion of the backup superblock is dependent on the filesystem’s
blocksize. For filesystems with 1k blocksizes, a backup
superblock can be found at block 8193; for filesystems with 2k
blocksizes, at block 16384; and for 4k blocksizes, at block
32768.
Additional backup superblocks can be determined by using the
mke2fs program using the -n option to print out where the
superblocks were created. The -b option to mke2fs, which spec-
ifies blocksize of the filesystem must be specified in order for
the superblock locations that are printed out to be accurate.
If an alternative superblock is specified and the filesystem is
not opened read-only, e2fsck will make sure that the primary
superblock is updated appropriately upon completion of the
filesystem check.

4 开始恢复.如果文件系统块大小为1K, 则我们可以用如下命令恢复:

# /sbin/fsck.ext3 -b 8193 /dev/hda4

如果这个备用块(8193)也有问题,那么 可以尝试 24577(8192*3+1) ,或者是 40961 (8192*5+1).

继续阅读

没有了MySQL,能用Linux做的事情多着呢

最近 Oracle 频繁收购开源厂商, 也有消息说 Oracle 也曾经试图收购 MySQL 未果, 一连串的事情引起了开源界的恐慌,估计也让不少开源爱好者都很闹心,今天居然在 CSDN 头条上看到了没有了MySQL,我们使Linux还能干什么这样的观点:

我宁可看到微软收购 Redhat、Mandrake等,也不愿看到 MySQL 被收购,因为在这之后将可能是 PostgreSQL 的覆灭,到了那时,我们还有什么理由继续使用 Linux 呢?

没错,这居然是 CSDN 的头条新闻. 这不知道这位开源爱好者怎么会作出这个有些可笑的结论.有必要讨论一下了。
 
被收购并不意味着会修改软件许可证方式.假定现在 MySQL 现在已经被某个大厂收购, 那么并不意味着这家收购方会冒天下大不韪,收购方可能会继续采用当前的许可模式,这样对那些期待免费使用的最终用户来说没甚么影响; 开源运动的实际推动者还是那些千千万万的软件爱好者,这一点不是以某个公司的意志能转移的。
修改软件许可方式不一定不是免费的. 我不知道那些 MySQL 的爱好者与使用者是重点关心软件价格的免费还是代码的开放, 据我的观察, 国内的 MySQL 最终用户中,直接因为某项功能而 Hack MySQL 源代码的少之又少,更多的都是直接拿来应用. 如果我的这一判断出入不大,那么 MySQL 被收购后不再开源,用户未必就一下子跑光了。
MySQL 不是唯一的开源数据库. 放眼望去,PostgreSQLIngresFireBird等等优秀的开源数据库产品还有很多; 除了流行程度, 软件功能和 MySQL 相差都不大; 即使收购方扼杀了 MySQL; 广大开源用户还是有的”吃”。
MySQL 本身的血统并不那么高贵. MySQL 本来就是由商业公司在背后运作, 甚至本身的技术也多少依赖于开源软件界。如果说他被更大的商业公司收购的话,只能说他的商业运作成功,修成正果而已。咱何必奢求?
更多厂商的推出免费数据库. Oracle 推出了免费的 Express Edition DB, IBM 紧跟对手推出免费的 DB2 Express-C, SybaseEnterpriseDB 等厂商也都有免费或开源的 DB 产品推出, 即使没有了 MySQL,我们的选择只会更多. “死了张屠户,也不用吃混毛猪”.
如果这些理由还没有解除你的顾虑, 现在我们看看数据库之外的东西。

继续阅读

用 Logwatch 工具监控 Linux 系统 Log 日志

如果要想迅速的得到 Linux 环境中的日志报告信息, Logwatch 是一个很好的工具.
一般的 Linux 系统中可能都默认安装了这个工具.几乎不需要额外的配置就可以简单的用起来.

# logwatch --print

这条命令将会把昨天的日志信息简要的打印出来. 比如用户登录失败信息、SSH 登录信息、磁盘空间使用等.
单独查看某个服务,比如 SSH 登录信息:

# logwatch --service sshd --print

这条命令可以查看使用说明:

# logwatch --help

最新版本的 LogWatch 默认有 70 多种 Log 的配置信息. 如果要对自己的特殊 Log 做监控, 定制也是比较容易的。简单记录一下:

继续阅读

The parameter list is too long

非常常见的一个 Unix/Linux 命令错误信息: The parameter list is too long.

$ find /backup/* -ctime 2
ksh: /usr/bin/find: 0403-027 The parameter list is too long.

find: 0403-027 The parameter list is too long 这个错误信息很让人迷惑: 难道该目录下文件太多了么? 其实不是的, 问题出在那个 “*” 上,Korn Shell 默认把 * 作为 Metadata 处理,进行了扩展,进而这条语句备错误的解析.我的操作平台是 AIX 5.3. 我不确定这是和这个平台的 Korn Shell 有关.
使用 ls / grep / find 等命令时侯因为通配符的使用, 一不小心就会遇到这样的错误.可以通过对对象添加引号来禁止扩展

继续阅读