The minix filesystem was the first (and initially, only) filesystem type available for Linux as, in its earliest incarnations, Linux sources needed a minix system so you could compile and run them.
From the user's point of view, the design of the minix filesystem is just the same as the System V filesystem from the previous section. However, as you will see, there are several differences between the two, which become apparent when you look at the internals.
To start with, minix uses a very similar arrangement to System V inside its inodes, to allocate data blocks to a file. The only real differences are that it uses only seven direct data block pointers and it does not support the triple indirect block pointer, making nine pointers in the mode in all. By default, mmix uses 1 Kb disk data blocks and l6-bit data block pointers. This means that an indirect disk block can hold 512 pointers, which gives a maximum filesystem size of just over 256 Mb (seven direct data blocks plus 512 data blocks via the single indirect block pointer plus 512x512 data blocks via the double indirect block pointer). At least, this would be the case were it not for the fact that with 16-bit block pointers you can only point at a maximum of 65536 data blocks (i.e. 64 Mb).
The layout of a minix filesystem on a disk partition is a little more complex than the System V equivalent, and is shown in Figure 1. Part of the reason for the extra complexity is that the minix filesystem uses the concept of zones as groups of data blocks, though, by default, zones and data blocks are the same thing and are both 1 Kb in size.
The rest of the extra complexity is because of the addition of the inode and zone bitmaps. Essentially, these replace the System V free inode and free data block lists in the super block. The advantage of bitmaps is that they take up relatively little space, as only a single bit is required for each inode and zone to specify whether it is in use or free. The practical consequence of this is that whole bitmaps can be stored in memory for as long as the filesystem is mounted. Searching a bitmap in memory is a far faster operation than sequentially searching through the inode array on disk, or reading a disk block's contents from the disk in order to fill the super block inode and data block free lists when this is required.
The reason for the zone bitmap rather than a data block bitmap is that disk space is allocated in zones. A zone is a power-of-two sized set of data blocks grouped together and treated as a single entity when it comes to allocating the space to a file. This means that a zone can be 1, 2, 4, 8, etc., data blocks in size (1 data block in size by default). With this arrangement it is possible to have minix filesystems that are larger than 64 Mb because all the pointers accessed via the inode are really pointing to zones which can be larger than the 1 Kb default.