Given a file with a single h in it. If I run find with the -ls primitive I get the following output:

$ cat some_file
$ find . -ls
2750606        0 drwxr-xr-x    4 mbigras          FOO\Domain Users      136 May 18 12:35 .
3067730       16 -rw-r--r--    1 mbigras          FOO\Domain Users     6148 May 18 12:33 ./.DS_Store
3067836        8 -rw-r--r--    1 mbigras          FOO\Domain Users        2 May 18 12:35 ./some_file

From man find and searching for -ls we can find the output is the following information about files:

its inode number, size in 512-byte blocks, file per- missions, number of hard links, owner, group, size in bytes, last modification time, and pathname.

Some things I'm wondering:

  • If some_file only has h in it which is one byte then why is the "size in bytes" 2? I would expect it to be 1.
  • If the second number is the "size in 512-byte blocks" then why is it larger than the "size in bytes"? I would expect it to be 0 or at least smaller.

some_file contains h followed by a newline, totaling two bytes. Try something like

hexdump -C some_file

to view the contents of the file byte by byte.

Any file between 1 and 512 bytes is going to take up one 512-byte block, if that is the minimum allocation size on the disk, just like a 513-byte file will take two 512-byte blocks. The block count is not rounded down to the nearest integer.

  • 1
    To further this answer, you can use the -n switch with echo to "not output the trailing newline". With echo -n "h" > some_file you will get a size of 1.
    – cutrightjm
    May 18 '17 at 19:53
  • 1
    We know the file contains a newline too, since that's what cat printed!
    – ilkkachu
    May 18 '17 at 20:10
  • So why is it 8 512-byte blocks instead of 1 512-block? @ilkkachu good catch cat is telling us! Because cat some_file gives h% which means there is no newline on OS X
    – mbigras
    May 18 '17 at 20:24
  • @mbigras, because the actual block size on your disk is 4096 bytes, not 512. If you are using OS X, issue diskutil info / | grep "Block Size" May 18 '17 at 20:37
  • So because the file contains 2 bytes OS X allocates 4096 bytes for that file, which is 512*8 and therefore there are 8 512-byte blocks allocated for that file?
    – mbigras
    May 18 '17 at 21:04

see what is the reason behind, why we use 512 bytes; let us say a file of size 513 bytes,than what happens is in order to store this file we need 2 blocks of size 512 bytes on the hard disk. In order to save the 513th byte we have to allocate a complete hard disk block which is containing 512 bytes right.So there is a wastage of 511 bytes because of internal fragmentation, so in order to reduce this internal fragmentation it is always better that you keep the size of block as small as possible and by experimentation we found out that 512 bytes is the size which is optimal, if you decrease it then you might have to access a lot of blocks in order to access a file and it will take time. So in order to optimize the things they found out that experimentally that 512 bytes is the better size in order to increase the efficiency and decrease the wastage of memory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.