Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!gryphon!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.os.minix
Subject: Re: Problems (mkfs and > 10000 block file systems)...
Message-ID: <4600@crash.cts.com>
Date: 12 Jul 89 01:36:25 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 68

jds@mimsy.UUCP (James da Silva) writes:
>John,
>
>I've got a Minix filesystem with somewhere above 18000 blocks on the second
>half of my 40 Meg Miniscribe.  I don't recall having any trouble making the
>filesystem.  I did happen to use a prototype.
>
>Several of the Minix utilities have the disk geometry hard-coded.  I
>beleive the list is: mkfs, fdisk, and fsck.  Check for constants giving the
>number of heads and number of sectors/track.  It's my guess that this is
>what is biting you.
>
All file system utilities have been recompiled with the appropriate hard coded
disk parameters (only the defines dealing with the numbers of heads is
appropriate here).  I have triple checked this.  So no, this is not what is
biting me.

>Are you referring to the trouble that standalone fsck has with filesystems
>out beyond the 32 meg (64k sectors) mark?  Forget about the standalone
>fsck.  You can build fsck to run under Minix, where it doesn't give a hoot
>about absolute sectors; it just works on the /dev/hdx file.  I've modified
>my tools/Makefile, changing what is currently the `fsck' binary to
>`fsck.stand', and adding (from memory):
>
>fsck: fsck.c
>	cc -o fsck -Di8088 fsck.c
>
>So I have both versions around.  fsck goes in /bin, and fsck.stand is used
>to build boot images.  You do have to be careful about fsck'ing an active
>filesystem.  I check my 18 Meg /u partition before mounting it.
>
Standalone fsck won't work from the Minix shell prompt because it makes calls
to the BIOS.  If you're using standalone fsck by mistake, you get interrupt
traps left and right.  My friend who has the problem system first tried
compiling fsck himself and found this out.  I compiled it in the manner you
described.  It works yes, my peeve is with mkfs, not fsck.  Mkfs has no
parameters hardcoded that I can see other than N_BLOCKS, I will try it with a
prototype file next time.  I know the i-node limitation is 8192 for the
current mkfs.

>>And now a bug report...
>> 
>>Minix 1.3 will work with the NCL FD/HD controller providing you don't use
>>Minix's fdisk.  Apparently the NCL controller has a difficult time writing
>>absolute sectors.
>
>Are you sure?  Check the constant for the # of heads in fdisk.c.
>
Yes, I am absolutely sure because the NCL AT FD/HD controller will NOT do an
absolute sector write under Norton Utilities 4.0 and 4.5.  If something
doesn't run with a very solid MS-DOS utility it sure as hell isn't going to
run under Minix.  NCL screwed up in designing their AT FD/HD controller.  You
can, however, edit the partition table under Norton if you do a cluster write.

Due to my problems with my OMTI 5520A and DMA, I am almost about ready to
throw in the towel on that thing and get a WD controller.  Until a smart
method such as what is used under SCO Xenix is devised for installing the OS
to the hardware configuration, my advice is to ONLY use 100% compatable
Western Digital Controllers or real Western Digital Controllers.  The latter
obviously being the safer bet on compatability.

 /*--------------------------------------------------------------------------*
  * Flames: /dev/null (on my Minix partition)
  *--------------------------------------------------------------------------*
  * ARPA  : crash!pnet01!jca@nosc.mil
  * INET  : jca@pnet01.cts.com
  * UUCP  : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
  *--------------------------------------------------------------------------*/