對這文章發表回應

大意就是　／ｐｒｏｃ目錄下的文件不真實存在、不佔用實際存儲設備空間（ 這個毋庸置疑 ） ， /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 查看下此文件：

在 64b 的  server 上查看：




從 file得到的屬性中，我們看以看出此 OS 的位數等， From 後邊跟的應該是 根分區的 UUID