For my own learning, I've been playing around with creating files with file holes. I created a util that simply reads from stdin and writes to a file, but before writing to the file, it uses lseek to move beyond the end of file by a number of bytes.
fh -b 20000 testfile
hello
there
After starting this process, input can be entered ("hello"), and written to testfile, but before it does, it seeks past end of file by 20000 bytes. Then before writing, it seeks again past end of file another 20000 bytes before "there" is written.
What I'm not clear on is the number of blocks allocated to the newly created file. If I do
ls -ls testfile
it shows 8 blocks are allocated, and the file size is 40013 (which is expected).
A new file with 13 bytes (but no file holes) allocates 4 blocks according to ls -ls
. I found out that this really means 1 block (2048 bytes for a block) but the blocks reported are divisible by 512 bytes. So presuming this is true, the math doesn't compute for the file with files holes. Why are 8 blocks allocated, shouldn't it still only be 4 since the physical file size is only 13 bytes (as opposed to logical size of 40013)?
I'm not sure if I'm reading the block size correctly, and secondly, I don't understand why the block size is 8 considering that a similar size file with no file holes has only 4.
I'm running Ubuntu 11.10 on an ext4 file system.