关于/proc/kcore 文件：
首先看来自：http://unixguide.net/linux/faq/04.16.shtml的原贴：
大意就是 ／ｐｒｏｃ目录下的文件不真实存在、不占用实际存储设备空间（这个毋庸置疑），/proc/kcore的大小等于内存的大小！
有人也觉得此文的件的大小是真实物理内存大小，看帖
看我的真实机子：
内存大小2g，与文件大小不符！
再看贴：
结论：不占用存储设备空间，但其大小不等于实际物理内存大小！！
上边大意就是 kcore 跟/proc 下的其他文件不同，它是显示大小的，而且它的大小等于已被使用的物理内存的大小 加上4k，此文件可以使用gdb 、objdump等工具调试。
很明显 如果是这样的话 那么kcore的大小应该至少939M，可其大小却是897M：
更诡异的是 ，上边显示的897M大小 还不是一直都存在的 ：
只不过是使用hexdump（或od） 查看了下，然后其就变成了4k，重新开机，恢复897M，再查看一次 又变成了4k。
然后我对内存进行存储数据，以消耗其空间：
作为一种特殊FS格式，tmpfs 是直接挂内存空间的，默认是内存空间大小的一半，当然也可以指定。
然后进行数据写入：
看以看到 内存和虚拟空间都基本已经耗尽了，再看kcore文件
其依然是4k。
重启以恢复内存和虚拟空间：
悲剧：
Swap分区依然存在，fstab中也有字挂在条目，却不能自动挂载（每次开机都是如此）。。。不得不每次都得：
Mkswap /dev/sda9 ; swapon /dev/sda9 来启用。
照此方法试了下，结果还是如此 - - ||
上面说kcore这个文件指的的可被内核分配的空间，但根据上边的实验来看，并非如此。其还提示说，在64b的OS中，这个文件大小最大可以达到128T，因为64b的OS最大寻址内存范围局势128T。
看着挺恐怖 - - ||（不过不用关心它）
用 hexdump查看下此文件：
能阅读的就只有 vmlinux LABELXXXX 你一部分
在64b的 server上查看：
从file得到的属性中，我们看以看出此OS的位数等，From后边跟的应该是 根分区的UUID
本文出自 “逆行者” 博客，请务必保留此出处http://monsterme.blog.51cto.com/2837715/1194000
转载于:https://blog.51cto.com/270390/1344911