Chuck_M_Grandgent@cup.portal.com (12/28/88)
I've probably been guilty of not reading ALL the mail, but here's the situation: IBM PC Minix 1.2, partially updated to 1.3, working fine, DOS 3.1. I've just gone and switched from a 20MB type-2 disk (Fuji), to a 40MB type 40 (Seagate ST-251). Had a devil of a time, but now working fairly well. 1) Successfully used the new changes to fdisk to specify number of heads on ST-251 (6). 2) Successfully used the old 'vol' and 'tar' to do a multi-volume floppy save of Minix on 20MB disk and restore on 40MB disk (not entirely painless) 3) All working OK, except fsck, which "can't handle partitions with sector numbers > 65336 (unsigned int). Gather the following changes necessary: change part_offset in fsck.c to a long instead of unsigned int, and then also routine diskio(), which is assembler needs to be changed to handle a long sector offset. Currently using BIOS function for diskio(), would have to use a different one I suppose. I'm really nervous about running without being able to use fsck, what do I need to do ? =================================================================== sun!portal!cup.portal.com!chuck_m_grandgent Chuck Grandgent, K1OM, AEG Modicon, Industrial Automation Systems Group ===================================================================
Chuck_M_Grandgent@cup.portal.com (01/06/89)
On my problem in not being able to run fsck because I stuck
my Minix in a partition with a sector offset >65536:
First, I wouldn't have put it there except all the documentation
on putting Minix on hard disk that I read warned that you had
better put DOS in the first partition. Also, I'd previously
had good luck with having DOS in /dev/hd1 and Minix in /dev/hd2.
I didn't know about the fsck limitation.
Second, thanks to those folks who EMailed me the suggestions
to put Minix in the bottom partition instead of DOS - I had
trouble getting replies out to you through Portal.
Third, at this point I really don't feel like moving Minix
down to the first partition, as that would take me another
week of work - I had enough of a hard time getting it to work
where it is - and except for fsck, it DOES seem to be working
just fine. Which brings to mind the question "how is the REST
of Minix dealing with the sector offsets for this partition
I'm using ?" I certainly would've run into problems by now, since
my setup is: Seagate ST-251 (40MB) with DOS in the first
partition, 32MB, and Minix in the second partition (8MB). I've
got about 5MB loaded into it, and it seems just fine.
Fourth, if possible, I'd rather fix fsck to work for the partitions
with sector offsets above the bottom 32MB.
I've looked into this with the following findings:
apparent Changes required:
fsck: change part_offset to a long
diskio() (fsck1.s) change the offset passed to it to a long.
Now the tough part of this is the required changes to fsck1.s.
The current diskio routine uses the Bios function 13h to do its
reads and writes. It APPEARS to me that it is capable of doing
I/O to stuff above the bottom 32MB.
Additional aritmetic needs to be done to separate an absolute
physical sector number into the corresponding cylinder #,
head #, and sector number, as required by int 13h.
INT 13H takes:
CH = cylinder #
CL, upper 2 bits : high order bits for cylinder #,
making a 10-bit cylinder #
CL, bottom 6 bits : sector number
DH = head #
Now, Bill Snyder on Compuserve sent me the following:
-------------------------------------------------------------------
> Fm: Bill Snyder 70425,115
> To: Chuck Grandgent 72330,450 (X)
>
> Given the number of heads and sectors per track, this should
> translate an 'abs_sec' number to 'cyl, hed, sec' coordinates:
>
> trak = abs_sec / secs_per_trk ;
> cyl = trak / heads ;
> hed = trak % heads ;
> sec = abs_sec % secs_per_trk + 1 ;
-------------------------------------------------------------------
Now, what I'm asking from you folks is if this all sounds
reasonable and feasible.
If so, I'll begin on trying to implement a (slightly) modified
fsck, and a new fsck1.s with new diskio() routine.
If there's some other reason I don't know about that's making
folks appear to avoid this issue like the plague, PLEASE LET
ME KNOW, so I don't go off on a wild goose chase !
===================================================================
sun!portal!cup.portal.com!chuck_m_grandgent
Chuck Grandgent, K1OM, AEG Modicon, Industrial Automation Systems Group
===================================================================