MINIX file system
| Developer(s) | Open Source Community |
|---|---|
| Full name | MINIX file system version 3 |
| Introduced | 1987 with MINIX 1.0 |
| Partition IDs | 0x81 (MBR) |
| Features | |
| Dates recorded | last metadata change, last file change, last file access |
| Date resolution | 1s |
| File system permissions | POSIX |
| Transparent compression | No |
| Transparent encryption | No (provided at the block device level) |
| Other | |
| Supported operating systems | MINIX 3, Linux and HelenOS |
The MINIX file system is the native file system of the MINIX operating system.
History
MINIX was written from scratch by Andrew S. Tanenbaum in the 1980s, as a Unix-like operating system whose source code could be used freely in education. The MINIX file system was designed for use with MINIX; it copies the basic structure of the Unix File System but avoids any complex features in the interest of keeping the source code clean, clear and simple, to meet the overall goal of MINIX to be a useful teaching aid.[1] When Linus Torvalds first started writing his Linux operating system kernel (1991), he was working on a machine running MINIX, so the initial releases based a lot of functionality on Minix subsystems.[2] Until the April 1992 introduction of the Extended file system, Linux used the MINIX file system.[3] The format is still used by some Linux distributions for bootable disks and other situations where a simple and compact file system is needed.[citation needed]
Design and implementation
A MINIX file system has six components:[1]
- The Boot Block which is always stored in the first block. It contains the boot loader that loads and runs an operating system at system startup.
- The second block is the Superblock which stores data about the file system, that allows the operating system to locate and understand other file system structures. For example, the number of inodes and zones, the size of the two bitmaps and the starting block of the data area.
- The inode bitmap is a simple map of the inodes that tracks which ones are in use and which ones are free by representing them as either a one (in use) or a zero (free).
- The zone bitmap works in the same way as the inode bitmap, except it tracks the zones.
- The inodes area. Each file or directory is represented as an inode, which records metadata including type (file, directory, block, char, pipe), IDs for user and group, three timestamps that record the date and time of last access, last modification and last status change. An inode also contains a list of addresses that point to the zones in the data area where the file or directory data is actually stored.
- The data area is the largest component of the file system, using the majority of the space. It is where the actual file and directory data are stored.
References
- ^ a b
Tanenbaum, Andrew S (14 January 2006). Operating Systems: Design and Implementation (3rd ed.). Prentice Hall. ISBN 0-13-142938-8.
{{cite book}}: Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Torvalds, Linus (2001). Just For Fun. Texere. ISBN 1-58799-080-6.
{{cite book}}: Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Card, Rémy (1994). "Design and Implementation of the Second Extended Filesystem". Proceedings of the First Dutch International Symposium on Linux. Retrieved 2007-03-23.
{{cite web}}: Unknown parameter|coauthors=ignored (|author=suggested) (help)