title: How can HDFS's 128M default block size minimize the seekTime / transferTime ratio
body: <p>I have been confused for quite a long time on this question. There are quite a few explanations on why HDFS using such a large block size comparing to the block size of os file system or the disk block. I understand the explanation saying that this will lower the traffic volume and storage requirements of NameNode for meta-data management. What I am always confused is the explanation on "minimizing seekTime /transferTime ratio". Just as the following post states.
  <a href="https://stackoverflow.com/questions/22353122/why-is-a-block-in-hdfs-so-large">Why Is a Block in HDFS So Large?</a></p>
  
  <p>I know my question might seem dumb cuz I am not from a CS degree background so I lack quite a few knowledge on topics like composition of modern computer etc. Please excuse me for that.</p>
  
  <p>My confusion is mainly caused due to following considerations:</p>
  
  <blockquote>
    <p>A block will be stored as a <strong>contiguous piece of information on the disk</strong>, which means that the total time to read it completely is the time to locate it (seek time) + the time to read its content without doing <strong>any more seeks</strong></p>
  </blockquote>
  
  <ol>
  <li>Is it the case that a whole HDFS Block will be stored on the disk in a continuously manner?</li>
  <li>When does the seek happens? It doesn't happen once per block on the disk?</li>
  <li>If it is store continuously then we can read the whole block with only one-time seek?</li>
  </ol>
  
  <p>I think my doubt has its ground since the conclusion of large HDFS block can reduce seek/transfer time ration can only be valid if all three conditions are met. Otherwise, the conclusion doesn't make sense to me.
  Hope anyone can tell me where I can find solid truth to prove my guess.Thanks in advance.</p>