This is minixfs version 0.60, quite a few changes have been made to this
version, some cosmetic, others not. The main filesystem code has now been
split up into several pieces, it was becoming far too large for a single
file. To compile edit the file 'dirs' setting FSDIR to wherever you want
minix.xfs to be put and UTILDIR to wherever the tools need to be placed;
then do a 'make install'.

	I have made several changes which should improve the filesystem
performance somewhat, my thanks to Steve Usher for politely pointing out how
bad the original version was :-) Other changes include, making the translation
parameters (e.g. with mfsconf) specific to a certain drive, so you can set 
different translation modes on different minix partitions.

	Two enhancements are responsible for most of the improvement. Lots
of dirty cache entries are dumped at once writing multiple sectors if possible.
Data is read in to the cache more than 1K at a time on read. The compilation
option PRE_READ determines how much to read in at once. Both of these improve
small record I/O somewhat. Writing to lots of different files will not give
much improvement.

	A side effect of my speed enhancements is to add a fair amount of
extra code. This tends to make the source even less readable. This is partly
due to the fact that several 'elegant' solutions I used before turned out to
be slow, so I've used uglier and faster ones. I also need to do a major tidy
up of the code. The compilation option ROBUST is now off by default, it
was originally intended to make the filesystem bomb-proof; now fsck exists it
isn't needed, it slows down the filesystem too much when set.

	The rest of this file describes the changes in pl3++

	I've had to do all manner of horrible things to get this going. The
main addition to this patch level is a bypass to the lrecno bug. If your hard
disk software is XHDI compliant then there are no problems. If not then if the
'huge' partition is one of the first sixteen bios drives (corresponding to
letters A-P inclusive) *and* your software is either ICD or some AHDI variant
then you should also be OK. There is a third way to bypass the problem:
physically save the partition boundaries to the binary, but this requires the
binary configuration program (see later) to work.

	If you've no idea what XHDI is then there are full details available
at ftp.uni-muenster.de in the archive pub/atari/Docs/xhdi-110.zoo .

	ICD software has a few caveats. The pun_info structure is different
for ICD and I can't find any more info about it so I've 'estimated' what the
precise form of it is; this seems OK up to 6.06 but I can't guarantee anything.
ICD software has an appalling bug (other than the stupid lrecno bug that occurs
in almost all ST hard disk software) which screws up when trying to read/write
physical mode with the cache on. Basically if you need to use huge partitions
with ICD software then you'll have to turn the cache off.

	I've tried to use all possible means to access partitions and to bypass
the stupid bugs. The current version uses no less than 5 different methods to
access partitions!

	A warning is in order here. These weird and wonderful new access methods
only come into play when really needed; that is if partitions are created that
are bigger than 64Mb (and necessarily V2). In my limited experience so far these
methods (whilst perfectly legitimate) use poorly tested features of hard disk
software so BE CAREFUL!!!!

	OK enough waffle; if you want to create a huge partition then 'minit -V'
should now handle things automagically. The restriction that the sector size
should be 1K or 512 bytes is now removed (it will be bigger than 1K anyway for
huge partitions). 'minit -t' has been altered somewhat: it tests several things
now and also goes through most of  the steps to create the filesystem, without
actually writing anything.

	Quick note about 'minit'. It needs a bit of an overhaul in the
protection department (keeping TOS away from the partitions without MiNT
running). I'll see if I can work out some semi-foolproof method for later
versions; this really is a complete pain to do and shouldn't be needed :-(

	fsck should also work on huge partitions.

	I'd be most grateful if someone would test out huge partitions. A good
FS workout would be:

	1. create with minit -V.
	2. Fill up the filesystem to bursting point.
	3. Run fsck at regular intervals.

	I could really do with this feature being checked before release. There
could easily be some bug lurking (particularly in fsck) which only rears it's
ugly head when huge partitions are accessed.

	A few other random musings: other stuff has been added to this patch
level, primarily to support a binary configuration program that is currently
'under construction' (I hope to send this out soon).

Have fun, Steve.