1

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 h $ 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.
Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
6
  • 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. Commented May 18, 2017 at 19:53
  • 1
    We know the file contains a newline too, since that's what cat printed! Commented May 18, 2017 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 Commented May 18, 2017 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" Commented May 18, 2017 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? Commented May 18, 2017 at 21:04
1

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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.