block allocation in unixFreeBSD

Question

From FreeBSD UNIX (Galvin),

Suppose data are written to a file in transfer sizes of 1-KB bytes, and the block and fragment sizes of the file system are 4 KB and 512 bytes. The file system will allocate a 1-KB fragment to contain the data from the first transfer. The next transfer will cause a new 2-KB fragment to be allocated. The data from the original fragment must be copied into this new fragment, followed by the second 1-KB transfer. The allocation routines do attempt to find the required space on the disk immediately following the existing fragment so that no copying is necessary, but if they cannot do so, up to seven copies may be required before the fragment becomes a block. Provisions have been made for programs to discover the block size for a file so that transfers of that size can be made, to avoid fragment recopying.

Can you please explain what the author is trying to say here? Why shouldn't a 4 kB block be allocated to write and then a 512 bytes fragment? Author is talking about general filesystem in UNIX.

Answer 1

The FreeBSD file system is apparently doing some moderately clever special processing for to prevent the "small files take up too much space because each one uses a disk block" problem that used to plague unix boxes after disks got big, but files systems still lived in the '80s.

This is good.

But if you write a medium to large file in small pieces, you can fool the file system into using the "small file" hack in a wasteful way.

This is bad. And slow. And tough on solid state "disk" devices.

If you write your medium to large files in chucks at least as big as a disk block, the "small file" hack isn't invoked. And none of those problems occur.

This is better.