File Systems and Volume Managers: History and Usage Page 3
File Allocation Comparison
One of the main reasons that many volume managers do not provide a round-robin allocation method is due to the interaction between the volume manager and the file system. Every file system must allocate space and maintain consistency, as this is one of the main purposes of the file system. There are multiple types of file system allocation, but the real issue is that a volume manager presents a single set address range for the block devices in the file system for the file system to allocate from, and the volume manager translates the address to each of the devices. It is difficult but not impossible for the volume manager to pass all of the underlying device topology to a file system. Also, just as important, most file systems designed with volume managers do not have an interface to understand the underlying volume topology.
How Volume Managers and File Systems Work
To choose the best file system for the application environment, it is important to fully understand how volume managers and file systems work internally. By understanding the inner workings of the software, you will have a much better idea what the tunable parameters represent and how to improve performance with those tunables for your available hardware and the application environment.
Each file system supports a method of how space is represented for files within the file system. The two most common methods are:
- Indirect blocks
If the file system is using extents-based allocation, space is allocated within the inode for block address locations for the file data. For most file systems, 15 extent addresses are used for the data in the base inode, and the last address in the inode is linked to another inode where an additional 15 extent addresses are available.
With indirect block allocation, the last block of space allocated for a file points to the next allocation. Space is allocated for the data in the base inode, and the last block of the allocated data space points to the next allocated space. Indirect blocks were originally designed for the UFS file system in 1970, when disks drives were slow and seeks were not required to go back to the inode and allocate additional space.
Here is an example of how Sun's UFS file system does allocation:
http://docs.sun.com/db/doc/801-6631/6i10bkb1a?a=view offers a helpful write-up on UFS internals.
Indirect block allocation and read/write performance is generally slower in comparison to the extents-based allocation method. I am unaware of any modern file systems using indirect blocks for space allocation because of the large performance penalties for random I/O. Even for sequential I/O, the performance for indirect blocks is generally still less than that of extents-based file systems.