轉 http://blog.csdn.net/samhacker/article/details/23089157?utm_source=tuicool&utm_medium=referral
一個常被問到的一個問題是： 如果一個HDFS上的文件大小(file size) 小於塊大小(block size) ，那么HDFS會實際占用Linux file system的多大空間？
答案是實際的文件大小，而非一個塊的大小。下面做一個實驗：
1、往hdfs里面添加新文件前，hadoop在linux上面所占的空間為 464 MB：
2、往hdfs里面添加大小為2673375 byte(大概2.5 MB)的文件：
2673375 derby.jar
3、此時，hadoop在linux上面所占的空間為 467 MB——增加了一個實際文件大小(2.5 MB)的空間，而非一個block size(128 MB)：
4、使用hadoop dfs -stat查看文件信息：
這里就很清楚地反映出： 文件的實際大小(file size)是2673375 byte， 但它的block size是128 MB。
5、通過NameNode的web console來查看文件信息:
結果是一樣的： 文件的實際大小(file size)是2673375 byte， 但它的block size是128 MB。
6、不過使用‘hadoop fsck’查看文件信息，看出了一些不一樣的內容—— ‘1（avg.block size 2673375 B）’:
值得注意的是，結果中有一個 ‘1（avg.block size 2673375 B）’的字樣。這里的 'block size' 並不是指平常說的文件塊大小(Block Size)—— 后者是一個元數據的概念，相反它反映的是文件的實際大小(file size)。以下是Hadoop Community的專家給我的回復：
“The fsck is showing you an "average blocksize", not the block size metadata attribute of the file like stat shows. In this specific case, the average is just the length of your file, which is lesser than one whole block.”
最后一個問題是： 如果hdfs占用Linux file system的磁盤空間按實際文件大小算，那么這個”塊大小“有必要存在嗎？
其實塊大小還是必要的，一個顯而易見的作用就是當文件通過append操作不斷增長的過程中，可以通過來block size決定何時split文件。以下是Hadoop Community的專家給我的回復：
“The block size is a meta attribute. If you append tothe file later, it still needs to know when to split further - so it keeps that value as a mere metadata it can use to advise itself on write boundaries.”