This page is under construction, these are preliminary notes, corrections requested

As originally distributed, Minix 2.0.0 could use a maximum of 16 MB of memory. A fix for this was posted in June 1998, and was incorporated into all later releases.

Disk and file sizes:

2.0.3, 2.0.4: The 4 gigabyte disk limit has been replaced by a 2 terabyte limit. (IDE disks still limited to 128G though. Individual partitions also still limited to 4G. See note below.) Maximum file size is slightly more than 64 Mbytes. Possible bug: Tar will poop out when you try to create an archive larger than this, and an attempt to transfer the file that is created over an ethernet will then crash the system.

2.0.0: The maximum size of a file system is 1 Gb for a version 2 file system, and 64 Mb for a version 1 file system. Alas the 8086 fsck runs out of memory on a V2 file system larger than 128 Mb, so for the 8086 version of MINIX you have to limit yourself to file systems of that size. a Minix file system can only contain 65535 inodes (files)

Accessing FAT file systems

Mtools was added to the standard Minix distribution with release 2.0.3.

Dosdir|dosread|doswrite can only access small FAT file systems. How small? I've hunted through archives of the newsgroup and mailing list to try to answer this. There have been various modifications to these tools over the years. Originally they were intended just for reading floppy disks (Minix itself did not originally support hard disks). Possibly the earliest version supported only FAT12 file systems -- there are notes from users who could not access 32 MB partitions. However, at some point the design was changed to support both FAT12 and FAT16 file systems, with block (cluster) sizes up to 4006 bytes. This would imply that a partition up to 256 MB size can be accessed. I found a note in the archives from Claudio Tantignone that suggested changing a constant in the source from 4096 to 8192, which would allow access to partitions up to 512 MB.

A volume formatted with the FAT file system is allocated in clusters. The default cluster size is determined by the size of the volume. For the FAT file system, the cluster number must fit in 16 bits and must be a power of two.

System	Bytes Per Cluster in FAT	Cluster limit
FAT12	1.5	< 4087 clusters
FAT16	2	4087 to 65525 clusters
FAT32	4	65526 to 268,435,456 clusters

By design FAT supports a maximum of 64K allocation units. When the disk partition is 32 megabytes or less, then an allocation unit is a 512 byte sector. However, as the disk gets larger, the units get larger. A 64 megabyte disk partition has 1K allocation units. A 128 meg partition has 2K units. A 256 meg partition has 4K allocation units. (source: http://www.yale.edu/pclt/BOOT/fat.htm)

Attribute	FAT12	FAT16	FAT32
Used For	Floppies and small hard disk volumes	Small to large hard disk volumes	Medium to very large hard disk volumes
Size of Each FAT Entry	12 bits	16 bits	28 bits
Maximum Number of Clusters	4,086	65,526	~268,435,456
Cluster Size Used	0.5 KB to 4 KB	2 KB to 32 KB	4 KB to 32 KB
Maximum Volume Size	16,736,256	2,147,123,200	about 2^41

(source: http://www.storagereview.com/guide2000/ref/hdd/file/partSizes.html)

More info on FAT file system partition (volume) size limits:

Block size	FAT-12	FAT-16	FAT-32
0.5 KB	2 MB
1 KB	4 MB
2 KB	8 MB	128 KB
4 KB	16 MB	256 MB	1 TB
8 KB		512 MB	2 TB
16 KB		1024 MB	2 TB
32 KB		2048 MB	2 TB

(source A.S. Tanenbaum, Modern Operating Systems, 2nd ed., p. 441)

Note on FS size (2006-06-20)

[From comp.os.minix. Question is about Minix 3, but answer is applicable to 
Minix 2, as well]

From: Ben Gras 
Newsgroups: comp.os.minix
Subject: Re: Minix uses 4GB HD at most?
Date: 20 Jun 2006 07:44:43 GMT
Message-ID: 

> I think 4GB is the limit of a Minix v3 filesystem.  You could create 
> more partitions, but I don't know what you would do with that much 
> space in Minix; you might install Linux in some of that space.

4GB is a limit, but not directly of the Minix filesystem. It is a limit
of the FS <-> device driver protocol. The FS talks to the device
drivers using minor device numbers, offsets in bytes (32 bit), and
sizes (32 bit).

I expect the filesystem to be able to work with 2^32 blocks, where each
block size is determined at mkfs time (4kB is the current default).
That would give rise to filesystems larger than any current disk.

The AT driver can completely address disks using LBA48.

It's only a matter of
 (a) The device driver protocol being extended to 64-bit offsets
     (actually this is already done and will soon be in cvs).
 (b) The filesystem being able to handle 64-bit file offset
     pointers (so that >4GB filesystems can be fscked). With
     a 64-bit seek call. This is a bit more work. :)

	=Ben