marc@skypod.uucp (Marc Fournier) (05/15/91)
Hi Folks... New question for the guru's out there... How do I change the kernel to accept 5 heads instead of 4? The Hard drive that I'm using has, obviously, 5 heads, but when trying to do a mkfs on a partition, I get an error if I try and go about 1895 blocks when the partition should hold about 19000 blocks. A friend of mine told me that the problem should be because wini.c is set up for 4 heads and not 5, but I can't find any variable that I can change from 4 to 5. Anyone have any ideas? thanks... -- | Marc G. Fournier (416) 250-8589 | Haven't thought of anything | | Toronto, Ontario | real witty to say here! | | uucp: marc@skypod.uucp --------- And probably... | | Bitnet: marc%skypod@ugw.utcs.utoronto.ca | never will! |
"Alfred C. McIntosh Jr." <amcintos@savanna-emh1.army.mil> (05/17/91)
You have to recompile xtwini or atwini, corrected for the correct number of disk he disk heads. Then, compile and relink the kernel. - should work.
marc@skypod.guild.org (Marc Fournier) (05/22/91)
In article <53806@nigel.ee.udel.edu> amcintos@savanna-emh1.army.mil (Alfred C. McIntosh Jr.) writes: >You have to recompile xtwini or atwini, corrected for the correct number of disk he >disk heads. Then, compile and relink the kernel. - should work. Hi Folks... I'm the guy that originally asked this question. First of all, I would like to thank the guys who answered telling me that I had to do an fdisk -h5 -s17 /dev/hdx to get it to work...it doesn't work but it gave me an idea to try out. If anyone ever has this trouble again, don't go looking through atwini or xtwini, you will be wasting your time..there isn't anything in there. Go directly to the fdisk.c source and change NHEAD in there. That is the only place that I could find any reference to HEADs at all. I wouldn't have been able to find it without two guys suggesting the fdisk -h -s /dev/hdx solution, so I have them to thank. As for the xtwini and atwini solutions...somebody want to tell me what system that is on, because I can't find it. By the way, I really enjoy minix...thanks for the help on any of the questions that I've asked in the past and thanks for the many more that I'll ask in the future... Till then...this was me... -- | Marc G. Fournier (416) 250-8589 | Haven't thought of anything | | Toronto, Ontario | real witty to say here! | | uucp: marc@skypod.guild.org --------- And probably... | | Bitnet: marc%skypod@ugw.utcs.utoronto.ca | never will! |
agm@daphne.stl.stc.co.uk (Andrew G. Minter) (05/23/91)
In article <1991May22.050418.189@skypod.guild.org>, marc@skypod.guild.org (Marc Fournier) writes: |> If anyone ever has this trouble again, don't go looking through |> atwini or xtwini, you will be wasting your time..there isn't anything in |> there. There are however some implicit assumtions about disk geometry in the FS. It's in read.c if I remember correctly and it's to do with doing read-ahead. Minix is supposed to read ahead the rest of the track following a read to increase speed. The trouble is, if the FS has a totally wrong idea about your geometry this can actually slow the file system down. Another problem here is that IDE drives often lie about their real geometry and pretend to have a different layout. They also tend to do track buffering in hardware. My inclination is to totally disable the read-ahead stuff. NOTE: This problem will *not* break anything, it's just a performance issue. Andrew -- +-----------------------------+--------------------------------+ | Andrew G. Minter | Email: agm@stl.stc.co.uk | | Principal Research Engineer | Phone: +44 279 429531 ext 3165 | | BNR Europe Limited | Fax: +44 279 454187 | | London Road, HARLOW | ITN: 782-3165 | | Essex CM17 9NA, UK | Telex: 81151 STL HW G | +-----------------------------+--------------------------------+
evans@syd.dit.CSIRO.AU (Bruce.Evans) (05/25/91)
In article <1991May22.050418.189@skypod.guild.org> marc@skypod.guild.org (Marc Fournier) writes: > I'm the guy that originally asked this question. First of all, I would >like to thank the guys who answered telling me that I had to do an >fdisk -h5 -s17 /dev/hdx to get it to work...it doesn't work but it gave me >an idea to try out. It should work, if 5 and 17 are correct. > If anyone ever has this trouble again, don't go looking through >atwini or xtwini, you will be wasting your time..there isn't anything in >there. Go directly to the fdisk.c source and change NHEAD in there. That >is the only place that I could find any reference to HEADs at all. I wouldn't >have been able to find it without two guys suggesting the fdisk -h -s /dev/hdx >solution, so I have them to thank. This is misleading. The number in fdisk.c don't affect anything much. For atwini, there is indeed nothing to fiddle with in the driver (this is good). The number of heads and sectors are read from a BIOS memory location, usually 0xF000:0xE401 + 0x10 * (drive_number - 1), where drive_number is what you tell setup. For xtwini, only the number of heads is stored in the BIOS table, and getting the correct index in the table is black magic. NR_SECTORS is defined in the driver as 17 unless it is already defined. But If you have defined AUTO_BIOS, a completely different method of getting the parameters is used. Changing DEFAULT_NHEAD in fdisk.c does nothing more than giving the -hheads parameter to fdisk. I think NHEAD was the name in the 1.3 version. -- Bruce Evans evans@syd.dit.csiro.au
evans@syd.dit.CSIRO.AU (Bruce.Evans) (05/25/91)
In article <4463@stl.stc.co.uk> agm@daphne.stl.stc.co.uk (Andrew G. Minter) writes: >There are however some implicit assumtions about disk geometry in the >FS. It's in read.c if I remember correctly and it's to do with doing >read-ahead. Minix is supposed to read ahead the rest of the track >following a read to increase speed. The trouble is, if the FS has a >totally wrong idea about your geometry this can actually slow the file >system down. Another problem here is that IDE drives often lie about >their real geometry and pretend to have a different layout. They also >tend to do track buffering in hardware. > >My inclination is to totally disable the read-ahead stuff. This is not a good idea. FS guesses 17 for the number of sectors per track. Disabling read-ahead would have a side effect equivalent to guessing 1 sector per track. Actually it doesn't matter much for hard disks because they either have decent buffering in the hardware or interleave is used to slow them down enough for the software to keep up. Then any large amount of read-ahead works well (except for random i/o). -- Bruce Evans evans@syd.dit.csiro.au