在Linode,我们一直在进行升级以利用他们的新SSD驱动器。我们在较旧的Ubuntu 10.10 32位系统上运行。
为了进行新的升级,我们一直在将内核从32位更改为“最新的64位”。到目前为止,这一直运行良好(我们运行的32位软件很高兴在64位内核中运行),但我想知道这是否会改变glibc。我唯一可能关注的Linode就是Linode,我们使用C编译器构建软件,并且我不一定要更改用于构建的glibc版本。
是的,我知道我们应该将实际的发行版升级到更新的64位Ubuntu,但这是一个更大的项目,而不是我们准备做的事情。所以目前我们只想使用最新的64位内核运行,因为它似乎没有造成任何伤害。我们目前只关注glibc对从C源创建构建的影响。
当然,如果有人知道运行64位内核的任何其他缺点,请随时发言!
谢谢,
道格
答案 0 :(得分:0)
看一下这个例子:
64位系统:
alex@rhyme ~/RPM $ ldd /bin/ls
linux-vdso.so.1 (0x00007fffef200000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f4b7b9d8000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f4b7b7b0000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f4b7b5a8000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007f4b7b398000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4b7afe8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4b7bc30000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4b7ade0000)
libpcre.so.3 => /lib64/libpcre.so.3 (0x00007f4b7ab98000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f4b7a990000)
alex@rhyme ~/RPM $ sudo chroot hsh/chroot/ /bin/bash
[sudo] password for alex:
[root@rhyme /]#
但是chrooted环境(用于构建)是32位:
[root@rhyme /]# ldd /bin/ls
linux-gate.so.1 (0xf7752000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf76f8000)
libselinux.so.1 => /lib/libselinux.so.1 (0xf76d0000)
libcap.so.2 => /lib/libcap.so.2 (0xf76c8000)
libacl.so.1 => /lib/libacl.so.1 (0xf76b8000)
libc.so.6 => /lib/libc.so.6 (0xf7540000)
/lib/ld-linux.so.2 (0xf7730000)
libpcre.so.3 => /lib/libpcre.so.3 (0xf74f8000)
libdl.so.2 => /lib/libdl.so.2 (0xf74f0000)
libattr.so.1 => /lib/libattr.so.1 (0xf74e8000)
[root@rhyme /]#
注意ldd输出的差异。 coreutils
(和ls
)的版本基本相同。
据我所知,使用64位内核可能会有一个缺点。在64位模式下,内核本身和控制结构需要稍多的内存(内核代码指令为64位)。除此之外,我没有注意到这种配置有任何问题。
BTW运行一个系统,其中32和64个二进制文件和库在单个系统中共存 被称为多拱(在上面的例子中没有多拱,因为第二个系统有自己的,独立的文件系统,我已经chrooted)。据我所知,Debian和Ubuntu都有可行的多arch支持,apt
的单个实例可以完美地管理32位和64位的包集。
因此理论上你可以进行慢速迁移",只需在32位对应文件旁边安装64位库,然后逐个替换32位到64位的二进制文件。当然,这不是最快的方式;-)但它可以几乎无缝,没有长时间停机或软件版本或行为的意外更改。当然,你的里程可能会有所不同,你应该仔细检查你的条件,环境等等。