如果说开发人员觉得这一切听起来有点耳熟,那么不妨直说吧:Poettering和Sievers在这方面的许多努力其灵感其实源自提供给使用Git版本控制系统的开发人员的键/值、散列和元数据这些概念。 实施The Journal不但会让Linux系统变得更安全(因为未经验证的日志条目或突如其来的数据字符项会立即被The Journal守护程序标出来),其发明者还希望通过统一Linux机器上的所有日志系统,为数据高效地重新建立结构,可以实际减少日志系统在Linux上占用的资源。 “其设计方式如下:日志数据只添加在末尾(目的是为了借助基于mmap()的访问,以确保健壮性和原子性),头里面的一些元数据变化可以引用新添加的日志数据。字段在日志文件中作为一个个对象来存储,然后可供有需要的所有条目来引用。这大大节省了磁盘空间,因为日志条目通常高度重复(想一想每个本地消息都会含有同样的_HOSTNAME=和_MACHINE_ID=字段)。数据字段经过了压缩,目的是为了节省磁盘空间。最终结果就是,虽然The Journal记入日志的元数据要比经典系统日志记入的多得多,但是占用的磁盘空间并没有立马体现这一点。” 然而,不是每个人都因这一提议而激动万分。Poettering和Sievers预料,许多开发人员和系统管理员不高兴The Journal使用通用唯一标识符(UUID)来识别消息,他们其实并不真正注意提议文档FAQ部分中的这个议题。 许多人在最先刊登这项提案的LWN上发表了反对意见,他们为简单的基于文本的系统将换成依赖The Journal这一种工具的二进制数据格式而悲痛,而这个工具将仅在systemd守护程序中存在。 有几个人在上面针对The Journal提议的FAQ留言道: “日志文件格式会实现标准化吗?我在哪里能找到磁盘上数据结构的解释?” “目前,我们不想对格式进行标准化。只要我们觉得合适,就想随意改变格式。我们可能最终会将磁盘上数据格式记入文档,但是眼下,我们不想使用其他任何软件来直接读取、写入或操纵我们的日志文件。我们需要一个共享库和命令行工具才能访问。(但是同样,这是自由软件,所以你总是能阅读源代码!)” 这引起了很大的争议,因为LWN上的许多读者反对为The Journal的数据使用非标准格式。向后兼容也是让人担心的一大问题。 其中一位读者C. McCabe留言道:“真遗憾,我们要失去明文syslog格式的简洁性。再说了,syslog通常使用gzip进行了压缩。所以实际上对我来说,这一切意味着,我将需要使用某个“神奇的工具”而不是gzcat作为我外壳命令的第一个部分。我发现的一大问题是,许多系统管理员会将这视作可以提高安全的魔法粉末,却没有认识到:为了获得任何安全方面的优点,他们需要定期将那些散列保存到远程而且安全的系统。” McCabe补充说:“我还希望Lennart及其公司认识到磁盘上数据格式向后兼容的绝对必要性。要是升级到新版本后,旧日志变得无法读取,这确实会激怒许多系统管理员。不过,假如这方面得当了妥善处理,我觉得这倒也算是个好想法。” 这在更广泛的Linux社区会引起怎样的反响?我本人认为,Fedora(及它的红帽爸爸)现在成了一个对Linux的许多内部基础架构进行改造的项目,而Ubuntu等发行版则侧重于界面和用户方面。 显然,Linux在经历一些重大的革命性变化,剔除了UNIX的一些糟粕。在Linux不断前进的同时,这些变化会给它带来怎样的影响,让我们拭目以待吧。 |