nall@nu.cs.fsu.edu (John Nall) (09/29/89)
I've been running Protected Mode Minix successfully on my 12-Mhz
AT-clone for some time. The 40 mb hard disk has three partitions,
with the first one assigned to DOS, the second for /usr and the third
one for root.
Last night, I tried to move Minix to a new 25-Mhz 386 system, with a
80 MB harddisk. From floppies, Minix (protected mode) runs fine. But
when I try to do a mkfs /dev/hd2 30000 (for example) it immediately
craps out with a message something like:
put_block failed
input line was line 1
Experimenting, I can do mkfs /dev/hd2 n, where "n" is a much smaller
number. For example, mkfs /dev/hd2 1000 works fine. So it would
appear that I'm running up against a number that is too large for
someone (write? ) to handle. Anyone have any experience with this?
I don't mind spending some time looking for the problem, but if someone
else has already solved it, I sure would appreciate knowing about it.
BTW, the disk is 9 heads, 1023 cylinders, 17 sectors per track, 512
bytes per sector. at_wini appears to work fine with it, using andy's
suggested test of dd if=/dev/hd0 of=/dev/null count=1000.
======================================================================
John Nall Internet: nall@nu.cs.fsu.edu
Computer Science Department Florida State University
"Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!"nall@nu.cs.fsu.edu (John Nall) (10/02/89)
With respect to my previous message regarding problems using
large disks with Minix, apparently the meaning of the message
was somewhat ambiguous. This message is intended both as a
summary of answers received, and as a clarification.
There are two issues regarding the use of large harddisks with
Minix. (a) Trying to use a large disk, but with no individual
partition greater than 32 MB. This was the problem that I was
dealing with. (b) Trying to use a Minix partition greater than
32 MB (on a large disk, obviously).
With regard to issue "a" the primary problem seems to be a
failure of mkfs, evidenced by a message of "put_block unable
to write". Andy pointed out that mkfs attempts to write the
very last block of the partition (being a non-trusting soul),
so the calculation has to be exact. He also points out that
there are several different partitioning programs, and that
some are less honest that others. So trust only fdisk from
Minix. When mkfs gives this message out, it is because there
was a write(fd,buf,nbytes) which returned a value less than
nbytes. In testing, I found that the value returned was very
consistently zero. One person who replied to my message
mentioned that he had found that the values used by at_wini did
not necessarily correspond to the exact values of his disk, so
that at_wini thought he was being given a bad address while
trying to write the last block of the partition. I have not
checked this out, since I solved the problem by a more careful
calculation of exactly how large the partition had to be (yes,
the whole thing was my stupid mistake!).
HOWEVER, with regard to issue "b", things get more interesting.
Just as a start, if one does mkfs /dev/hd2 40000" for example,
an error occurs right off the bat, since the 40000 is read into
a integer variable called "blocks" and is thus a negative number.
I suspect that this is a fairly good indicator of the general
problem in this area -- that it is going to be a matter of going
through and locating the places where unsigned integers should be
substituted. I'm willing to donate my system to trying to do this
for awhile (that is, a continual round of destroying the hard disk!)
so if someone wants to suggest anything, I'm game to try it. In the
meantime, I'm going to start slogging through the code on my own, as
Andy requested, and will report whatever I find.
As an aside, it seems to me that shooting for a partition size of 64MB
is a reasonable thing to expect, so the 16-bit limit is not any
particular problem. However, I would hope that with the release
of Minix Version 2.0, there would be a compilation parameter
(size_t??) which would allow a 32-bit integer to be used. Also,
if we MUST have hard-wired disk parameters, such as number of
heads, number of sectors, etc., etc., can they be put into a
single #include file, rather than stuck willy-nilly into separate
programs?
======================================================================
John Nall Internet: nall@nu.cs.fsu.edu
Computer Science Department Florida State University
"Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!"ast@cs.vu.nl (Andy Tanenbaum) (10/03/89)
In article <233@vsserv.scri.fsu.edu> nall@nu.cs.fsu.edu (John Nall) writes: >Just as a start, if one does mkfs /dev/hd2 40000" for example, >an error occurs right off the bat, since the 40000 is read into >a integer variable called "blocks" and is thus a negative number. John- If you could find the places in mkfs that should be unsigned and get that fixed, please post the cdiffs. I am certainly very interested and I am sure others are too. >However, I would hope that with the release >of Minix Version 2.0, there would be a compilation parameter >(size_t??) which would allow a 32-bit integer to be used. Also, >if we MUST have hard-wired disk parameters, such as number of >heads, number of sectors, etc., etc., can they be put into a >single #include file, rather than stuck willy-nilly into separate >programs? As far as I know, heads, tracks, etc should not be needed any more. The only reason was to run mkfs, fsck etc stand-alone on floppy disk systems. As far as I am concerned, that is over, and mkfs and fsck are just regular MINIX programs. I don't believe any MINIX programs use heads, tracks etc. any more, but correct me if I have missed something. As to 32 bit disk address, I don't know if you understand what you just said. I suspect not. Unfortunately, I know very well what you just said. I haven't brought the subject up yet because it is an unpleasant one, but invariably somebody else will see the problem too and bring it up, so I might as well go first. The MINIX i-node is 32 bytes. This was designed to be frugal on a floppy based system. The 32 bytes contain 9 16-bit disk addresses and a few other goodies. Going to 9 24-bit addresses (like UNIX) takes up 27 bytes. Since we also need the mode, at least one time (a long), a gid, uid, etc, it is not going to fit. Furthermore, POSIX really requires three distinct times in the i-node, not 1 like MINIX has. The implication of all this is that we have to go to a 64-byte i-node. Not that this is so awful, and technically it is not a problem, but it does mean that the V2.0 file system will not be compatible with the 1.x file system (choke!). I have been aware of this since I read the POSIX standard and saw that one must have three times in the i-node, since the standard tells exactly when each time is updated, and test suites can easily verify this. What do people think about a 64-byte i-node with 3 times and 24-bit disk addresses (32-bits is overkill, and I'd rather have 13 addresses in the i-node, just like UNIX). Due to the bit maps, the disk layout can't be UNIX compatible, however. An obvious question is how do people convert? One thought is that you first tar your entire file system to diskette in tar format (or PAX or whatever we have at that time). Then you build a new V2.0 MINIX boot diskette, turn the computer off, and reboot. Next step is mkfs on your disk, erasing everything, and setting up a new file system with 64-byte i-nodes. Then you read back the tar diskettes. I don't think I need explain what happens if you make a mistake somewhere. I'll bet you didn't realize what a can of worms you were opening with that remark about 32 bits! As to size_t etc, POSIX specifies quite a few types, and I will try to use them. Andy Tanenbaum (ast@cs.vu.nl)
n62@nikhefh.nikhef.nl (Klamer Schutte) (10/03/89)
In article <3463@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
#>The MINIX i-node is 32 bytes. This was designed to be frugal on a floppy
#>based system. The 32 bytes contain 9 16-bit disk addresses and a few other
#>goodies. Going to 9 24-bit addresses (like UNIX) takes up 27 bytes.
24 bit addresses are not to efficient on a 68000: needs a lot of
shift operations to come a decent integer type (long/short).
#>Since we also need the mode, at least one time (a long), a gid, uid, etc,
#>it is not going to fit. Furthermore, POSIX really requires three distinct
#>times in the i-node, not 1 like MINIX has. The implication of all this is
Where is that in the standard? In my version (1986) paragraph
5.6.1.2 says:
Only st_mode, st_ino, st_dev, st_uid, st_gid, st_size and st_mtime
are requiered data elements in the stat structure. All other
elements are optional, ... (etc.)
So reading this whole section i think we are POSIX-compatible if
we delete the fields st_atime & st_ctime from stat.h!
#>that we have to go to a 64-byte i-node. Not that this is so awful, and
#>technically it is not a problem, but it does mean that the V2.0 file
#>system will not be compatible with the 1.x file system (choke!). I have
#>been aware of this since I read the POSIX standard and saw that one must
#>have three times in the i-node, since the standard tells exactly when each
#>time is updated, and test suites can easily verify this.
where can i find this?
<...>
#>An obvious question is how do people convert? One thought is that you
#>first tar your entire file system to diskette in tar format (or PAX or
#>whatever we have at that time). Then you build a new V2.0 MINIX boot
#>diskette, turn the computer off, and reboot. Next step is mkfs on your
#>disk, erasing everything, and setting up a new file system with 64-byte
#>i-nodes. Then you read back the tar diskettes. I don't think I need
#>explain what happens if you make a mistake somewhere.
Saver will be: write a program which reads the old file system
when running the new kind. And mount first only new type file
systems. Just then mkfs the old file systems when you are sure
you have transferred the old data.
#>
#>Andy Tanenbaum (ast@cs.vu.nl)
Klamer.
--
____________________Yes, mail address changed again :-(_________________________
Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhef.nlbeattie@visenix.UUCP (Brian Beattie) (10/03/89)
In article <3463@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >An obvious question is how do people convert? One thought is that you >first tar your entire file system to diskette in tar format (or PAX or >whatever we have at that time). Then you build a new V2.0 MINIX boot >diskette, turn the computer off, and reboot. Next step is mkfs on your >disk, erasing everything, and setting up a new file system with 64-byte >i-nodes. Then you read back the tar diskettes. I don't think I need >explain what happens if you make a mistake somewhere. > >Andy Tanenbaum (ast@cs.vu.nl) I would suggest that the new kernel and bootdisk be able to read both types of inodes. This could be done by switching on the Magic number of the filesystem. This approach has several benefits, it would be possible to use the smaller inodes on a floppy, the migration could be done one filesystem at a time. The amount of extra code necessary should be very small it is only the reading of the inode into the incore structure that is different. -- Do Not meddle in the | Brian Beattie (703)471-7552 affairs of Wizards, | 11525 Hickory Cluster, Reston, VA. 22090 for you are crunchy | beattie@visenix.UU.NET and go well with catsup| ...uunet!visenix!beattie
HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (10/03/89)
ast@CS.VU.NL writes: >In article <233@vsserv.scri.fsu.edu> nall@nu.cs.fsu.edu (John Nall) writes: >>Just as a start, if one does mkfs /dev/hd2 40000" for example, >>an error occurs right off the bat, since the 40000 is read into >>a integer variable called "blocks" and is thus a negative number. > ... >>However, I would hope that with the release >>of Minix Version 2.0, there would be a compilation parameter >>(size_t??) which would allow a 32-bit integer to be used. Since disks are getting fairly big, and since 24-bit integers are used by Un*x to specify block numbers in inodes (see below), it seems Minix should be coherent and allow for large disks in all the system utilities if the file system is changed to allow it. >As to 32 bit disk address, I don't know if you understand what you just >said. I suspect not. Unfortunately, I know very well what you just said. >I haven't brought the subject up yet because it is an unpleasant one, but >invariably somebody else will see the problem too and bring it up, so I might >as well go first. > >The MINIX i-node is 32 bytes. This was designed to be frugal on a floppy >based system. The 32 bytes contain 9 16-bit disk addresses and a few other >goodies. If I need a 100Mb partition when I get C-news up, I'll need more bits for block addresses in the inode :-) ! (Bigger blocks could be considered, but lots of disk would be wasted on short news articles) >What do people think about a 64-byte i-node with 3 times and 24-bit disk >addresses (32-bits is overkill, and I'd rather have 13 addresses in the >i-node, just like UNIX). Due to the bit maps, the disk layout can't be >UNIX compatible, however. > ... > >Andy Tanenbaum (ast@cs.vu.nl) -- Guy Helmer AT&T: (605) 256-5315 Dakota State University Computing Services (605) 256-6411 BITNET: HELMER@SDNET
henry@utzoo.uucp (Henry Spencer) (10/04/89)
In article <3463@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >An obvious question is how do people convert? One thought is that you >first tar your entire file system to diskette in tar format (or PAX or >whatever... Other things being equal, the right way to convert is to implement something like the Eighth Edition filesystem switch in the kernel, so the kernel simply understands both kinds of filesystem. This makes life enormously simpler for everyone except the kernel implementor. Only a few things should really need to know inode format and block-number size; they can present a common interface to the rest of the kernel. Presumably this would be the new interface, with the old one done as a subset. -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ast@cs.vu.nl (Andy Tanenbaum) (10/04/89)
In article <275@nikhefh.nikhef.nl> Schutte@nikhefh.nikhef.nl (Klamer Schutte) writes: >In article <3463@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >#>one must >#>have three times in the i-node, since the standard tells exactly when each >#>time is updated, and test suites can easily verify this. > where can i find this? Start with Table 5-1. Then read Sec. 2-4, page 36: "Each file has three associated time values ..." All over the standard are requirements like 5.6.6.2" "Upon successful completion, the utime() function shall mark for update the st_ctime field of the file." It is easy enough for a test suite to stat a file, do a utime on it and stat it again to see if st_ctime was changed. The standard is full of requirements like this. Andy Tanenbaum (ast@cs.vu.nl)
ast@cs.vu.nl (Andy Tanenbaum) (10/04/89)
In article <1989Oct3.170941.7177@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >something like the Eighth Edition filesystem switch in the kernel, so >the kernel simply understands both kinds of filesystem. While this might help, there are some utilities that actually know about the disk layout, such as mkfs, fsck, readfs, de, etc. All these would have to have the same switch. I am inclined to say this is too complicated compared to a one-time tar-out + tar-in. Andy Tanenbaum (ast@cs.vu.nl)
nall@loligo.cc.fsu.edu (John Nall) (10/04/89)
In a previous message, I complained about the inability
of Minix to use partitions greater than 32 MB. In response,
Andy posed a general question as to what problems might
exist regarding this.
This is kind of an "alpha version" of tentative results of
an investigation (that is, take it with a grain of salt, but
it might be useful....I'll report in greater detail later).
Fdisk seems to have no problem making a partition greater
than 32 MB. Be aware that you should give it a parameter
as to how many heads your disk has! Otherwise, he makes the
assumption that it only has four! So use "fdisk -5"
(or whatever).
Mkfs has a couple of easily solved problems. There is a
variable called "blocks" which is declared as int. It should
be unsigned int. There is also a variable called "nrblocks"
which has the same problem. There is also a #define statement
which declares N_BLOCKS to be 32000. I set this to 65528 (as
it specifies that it has to be divisible by 8, and 65536 would
be a little big, I would think).
After this, mkfs /dev/hd5 40000 worked OK. Prior to that, it
would work for 32767 but blew up on 32768 (and greater). This
also implies that at_wini works OK, since it writes the last
block!
After I check further, I'll post patches.
======================================================================
John Nall Internet: nall@nu.cs.fsu.edu
Computer Science Department Florida State University
"Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!"nfs@notecnirp.Princeton.EDU (Norbert Schlenker) (10/04/89)
In article <275@nikhefh.nikhef.nl> Schutte@nikhefh.nikhef.nl (Klamer Schutte) writes: ]In article <3463@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: ]#>The MINIX i-node is 32 bytes. This was designed to be frugal on a floppy ]#>based system. The 32 bytes contain 9 16-bit disk addresses and a few other ]#>goodies. Going to 9 24-bit addresses (like UNIX) takes up 27 bytes. ] 24 bit addresses are not to efficient on a 68000: needs a lot of ] shift operations to come a decent integer type (long/short). ]#>Since we also need the mode, at least one time (a long), a gid, uid, etc, ]#>it is not going to fit. Furthermore, POSIX really requires three distinct ]#>times in the i-node, not 1 like MINIX has. The implication of all this is ] Where is that in the standard? In my version (1986) paragraph ] 5.6.1.2 says: ] Only st_mode, st_ino, st_dev, st_uid, st_gid, st_size and st_mtime ] are requiered data elements in the stat structure. All other ] elements are optional, ... (etc.) ] So reading this whole section i think we are POSIX-compatible if ] we delete the fields st_atime & st_ctime from stat.h! The 1988 standard says, in 5.6.1, that all of the following are required and must have meaningful values: st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, st_mtime I count that to use at least 20 bytes. Adding other useful information (like disk addresses!), 32 bytes is not going to be enough. ]#>that we have to go to a 64-byte i-node. Not that this is so awful, and ]#>technically it is not a problem, but it does mean that the V2.0 file ]#>system will not be compatible with the 1.x file system (choke!). I have ]#>been aware of this since I read the POSIX standard and saw that one must ]#>have three times in the i-node, since the standard tells exactly when each ]#>time is updated, and test suites can easily verify this. ] where can i find this? In the 1988 standard, there is additional discussion in 2.4 under "file times update". There is no getting away from this. ]#> ]#>Andy Tanenbaum (ast@cs.vu.nl) ] ]Klamer. ]-- ]____________________Yes, mail address changed again :-(_________________________ ]Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhef.nl Norbert
nall@nu.cs.fsu.edu (John Nall) (10/04/89)
The following are the (very minor) changes to mkfs.c which will allow
it to make a file system greater than 32 MB. No guarantees come with
the code, but I have tested it fairly extensively, making a 40 MB
partition (checks out mkfs), copying most of an existing 20 MB partition
to it (checks out at_wini), and doing random checks on the resulting
files. (A du of both partitions looked good). I also used fsck on the
40 MB partition, and it appears successful.
One minor problem which I have not fixed -- df prints out negative
numbers when the number of blocks is greater than 32K. I looked at
the code in df, and it is more of a hassle to fix it than it is worth
right now (the negative number is easily mentally converted to the
right value).
This is, of course, a listing from cdiff.
---------------------------cut here------------------
*** /usr/minix/tools/mkfs.c Thu Jul 13 10:43:31 1989
--- /usr/minix/commands/mkfs.c Tue Oct 3 16:06:41 1989
***************
*** 45,52 ****
#define BIN 2
#define BINGRP 2
#define BIT_MAP_SHIFT 13
! #define N_BLOCKS 32000 /* must be multiple of 8 */
!
#ifdef DOS
# define BREAD 4
# define BWRITE 5
--- 45,52 ----
#define BIN 2
#define BINGRP 2
#define BIT_MAP_SHIFT 13
! #define N_BLOCKS 65528 /* must be multiple of 8 */
! /* (65536 is a no-no) */
#ifdef DOS
# define BREAD 4
# define BWRITE 5
***************
*** 56,65 ****
#endif
! int next_zone, next_inode, zone_size, zone_shift=0, zoff, nrblocks,inode_offset,
! nrinodes, lct=1, disk, fd, print=0, file=0, override=0, simple=0, dflag;
! int donttest; /* skip test if it fits on medium */
!
long current_time, bin_time;
char zero[BLOCK_SIZE], *lastp;
char umap[(N_BLOCKS+8)/8]; /* bit map tells if block read yet */
--- 56,65 ----
#endif
! int next_zone, next_inode, zone_size, zone_shift=0, zoff, inode_offset,
! nrinodes, lct=1, disk, fd, print=0, file=0, override=0, simple=0, dflag;
! int donttest; /* skip test if it fits on medium */
! unsigned int nrblocks;
long current_time, bin_time;
char zero[BLOCK_SIZE], *lastp;
char umap[(N_BLOCKS+8)/8]; /* bit map tells if block read yet */
***************
*** 79,86 ****
int argc;
char *argv[];
{
! int i, blocks, zones, inodes, mode, usrid, grpid, badusage = 0;
! char *token[MAX_TOKENS], line[LINE_LEN];
FILE *fopen();
long time(), ls;
struct stat statbuf;
--- 79,87 ----
int argc;
char *argv[];
{
! int i, zones, inodes, mode, usrid, grpid, badusage = 0;
! char *token[MAX_TOKENS], line[LINE_LEN];
! unsigned int blocks;
FILE *fopen();
long time(), ls;
struct stat statbuf;
======================================================================
John Nall Internet: nall@nu.cs.fsu.edu
Computer Science Department Florida State University
"Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!"ast@cs.vu.nl (Andy Tanenbaum) (10/05/89)
In article <241@vsserv.scri.fsu.edu> nall@loligo.cc.fsu.edu (John Nall) writes: >This is kind of an "alpha version" of tentative results Keep up the good work and please post cdifs when you get it straightened out. I hadn't realized that fdisks quietly assumed 4 heads. That is probably very dangerous nowadays. One solution is to force the number of heads as a parameter, and give a Usage: message is not supplied. Any other ideas? At the Efficiency Beurs, I tried fdisk on some machines and it said the partition table was empty (all 0s). Is that because all those disks had more than 4 heads, or do clones keep the partition table somewhere else these days? Andy Tanenbaum
jca@pnet01.cts.com (John C. Archambeau) (10/05/89)
ast@cs.vu.nl (Andy Tanenbaum) writes: >At the Efficiency Beurs, I tried fdisk on some machines and it said the >partition table was empty (all 0s). Is that because all those disks had >more than 4 heads, or do clones keep the partition table somewhere else >these days? No, I had this problem with a fived headed drive. It didn't give me all zeros, just a strange partition table. You can fix fdisk by changing the define macro NR_HEADS (or HEADS?) to the number appropriate for your drive and everything works. Same thing for fsck. The partition table is always in the same spot in the first sector of the disk. Of course, as hard drives get large, the larger the partition table should be since it can accomodate more file systems and of course more operating systems. Also, if one uses Disk Manager, it uses a 'modified' partitioning scheme to give you more than 4 partitions which is the IBM de facto standard. We could always adopt the BSD 4.2 file system and have partitions a through f with c being the whole logical drive if one desires an efficient file system. :) /*--------------------------------------------------------------------------* * 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 *--------------------------------------------------------------------------* * Note : My opinions are that...mine. My boss doesn't pay me enough to * speak in the best interests of the company (yet). *--------------------------------------------------------------------------*/
nall@loligo.cc.fsu.edu (John Nall) (10/05/89)
> I hadn't realized that fdisks quietly assumed 4 heads. That is probably > very dangerous nowadays. One solution is to force the number of heads > as a parameter, and give a Usage: message if not supplied. Any other ideas? > Andy Tanenbaum I think the Usage: message should certainly be given! There are a small but vital group of programs which new users are going to have to use just to get started, and these should be made as foolproof as possible, since these users are not yet knowledgeable about Minix. Also, I am not sure that one can assume that a user necessarily KNOWS all of the pertinent info about the harddisk. I had to use the Norton Utilities under DOS to get the info I needed. So perhaps some kind soul could write a "hdinfo" program which would print it out upon demand, for new users. John Nall ====================================================================== John Nall Internet: nall@nu.cs.fsu.edu Computer Science Department Florida State University "Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!"
ncoverby@ndsuvax.UUCP (Glen Overby) (10/05/89)
In article <3491@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >I hadn't realized that fdisks quietly assumed 4 heads. That is probably >very dangerous nowadays. One solution is to force the number of heads >as a parameter, and give a Usage: message is not supplied. Any other ideas? yes! use ioctl to get the number of disk heads, cylinders, etc. from the wini driver. I tried implimenting this a while back, but I found out the hard way that ioctl only knows about ttys. I can't recall all the details, but I do remember that ioctl() copies it's parameters into a message, and I had trouble making all the disk geometry parameters fit. FS also knows about this (lines 12307-12315 in the Book). My feeling is that ioctl() should pass a pointer to it's i/o parameter, and the device should copy it in and out of user space. This is more work, but it's also more versatile. And it's not like ioctl's are done that many times a second. I think it would also be very useful to be able to SET the disk geometry parameters in the driver with the ioctl; I belive the RLL problem would then be a simple ioctl changing the number of sectors/track and retry timer. Thats all I had to change in the code (1.3D) for an Adaptec RLL controler> Also on my "fix" wish-list is a fdisk that knows what a DOS 16-bit FAT partition is. Right now it lists it as unknown (or something like that). >more than 4 heads, or do clones keep the partition table somewhere else >these days? Every machine I ever encountered had a pretty much standard partition table (sector 0 of the entire drive). The number of heads, etc. shouldn't have mattered. Western Digital stores all their drive parameters there... -- Glen Overby <ncoverby@plains.nodak.edu> uunet!ndsuvax!ncoverby (UUCP) ncoverby@ndsuvax (Bitnet)
ast@cs.vu.nl (Andy Tanenbaum) (10/06/89)
In article <2988@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes: >I think it would also be very useful to be able to SET the disk geometry >parameters in the driver with the ioctl Ioctl really isn't for disks. It would be best if the driver could figure out the geometry itself. I thought it made some BIOS call for this, but I didn't write at_wini.c, and am not really sure. If something is wrong there, it should be fixed. >Also on my "fix" wish-list is a fdisk that knows what a DOS 16-bit FAT >partition is. Right now it lists it as unknown (or something like that). Anybody with some knowledge of DOS want to volunteer for this? Fdisk is clearly an important program and should get it right. Andy Tanenbaum (ast@cs.vu.nl)
henry@utzoo.uucp (Henry Spencer) (10/08/89)
In article <3541@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >>I think it would also be very useful to be able to SET the disk geometry >>parameters in the driver with the ioctl > >Ioctl really isn't for disks. It would be best if the driver could figure >out the geometry itself... The reason for the switch from gtty/stty to ioctl was the observation that such operations were useful for more than just ttys. Yes, I have seen disk drivers with ioctls; in fact, I've written one. (Being able to set tuning parameters without recompile/reboot enormously speeded up some experiments with said parameters, and the result was a doubling of disk throughput. It's also a much better way to read disk-usage statistics than grubbing through /dev/kmem.) -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
evans@ditsyda.oz (Bruce Evans) (10/09/89)
In article <3541@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Ioctl really isn't for disks. It would be best if the driver could figure >out the geometry itself. I thought it made some BIOS call for this, but The driver has its own problems deciding the geometry (it uses magic :-)), but the original suggestion was for user-level ioctls so programs like fdisk could find the number of heads instead of using the same or different magic. The original ioctl interface is barely adequate for TTY, let alone disks, and would require masses of code in the library for all the POSIX ioctls, so is not worth keeping. Bruce -- Bruce Evans evans@ditsyda.oz.au
pcm@iwarpr0.intel.com (Phil C. Miller) (10/10/89)
In article <223@vsserv.scri.fsu.edu> nall@nu.cs.fsu.edu (John Nall) writes: >I've been running Protected Mode Minix successfully on my 12-Mhz >AT-clone for some time. The 40 mb hard disk has three partitions, >with the first one assigned to DOS, the second for /usr and the third >one for root. By root, do you mean the directory "/" or the root file system? >Last night, I tried to move Minix to a new 25-Mhz 386 system, with a >80 MB harddisk. From floppies, Minix (protected mode) runs fine. But >when I try to do a mkfs /dev/hd2 30000 (for example) it immediately >craps out with a message something like: > put_block failed > input line was line 1 >Experimenting, I can do mkfs /dev/hd2 n, where "n" is a much smaller >number. For example, mkfs /dev/hd2 1000 works fine. So it would >appear that I'm running up against a number that is too large for >someone (write? ) to handle. Anyone have any experience with this? I have experience (not a solution) with the same problem. I have a disk similar to yours. In experimenting with my system, I found that the limit on my system was exactly n=4080. I have the /usr partition in the second slot (same as you) and I have several partitions following /usr. Judging from the fact that 4080 is not a nice round number (like 4096, for example), I would guess that it is a parameter to some function which produces a number too big for 16 bits. >====================================================================== >John Nall Internet: nall@nu.cs.fsu.edu >Computer Science Department Florida State University > "Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!" Phil Miller pcm@iwarp.intel.com or {...}!tektronix!ogccse!pcm