rheffel@cs2.wsu.edu (04/09/89)
I have just applied the patch from bugs.nosc.mil to kernel/floppy.c and dos[dir, read, write] so that 1.44M and 720K drives will be supported. In the comments, the author of the patch states that if you are going to use 1.44M drives, either make a new special file or modify the block size of an existing one. ForOn page 398 of AST's book, ast states "For special files, the major an minor devices are needed. The size in blocks must also be specified for block special files (the MINIX block size is 1K; ...)". We all know that storage devices are block devices. In fact, the sample file system on that page shows that /dev/fd0 is 3600K. In proto.ram in the tools subdirectory /dev/at0 is 1200K. Ahah, the question I am driving at is how to create a new special file short of using mkfs with a new line inserted in such as "ps0 b--644 2 1 2 0 1440" and similarly for ps1. I ask because mknod (incidentally on the same page 398) allows you to create a special file. For example, "mknod ps0 b 2 0" will create a special file ps0 without using mkfs. The trouble is that the upper bound on creating a file system on a 3 and 1/2 inch diskette is 1200K. Notice how this corresponds to the largest value for a device with major == 2. Is there some way of increasing the block size for a device with major == 2 short of using mkfs to write a new file system. I ask because the file system I want to modify is on my hard disk. Secondly, what should the value of the block size for a 1.44M drive be. Such a drive formats a diskette to 1,457,664 bytes. 1,457,664 / 1024 = 1423.5. Round this value of 1423.5 up to 1423? Finally, where is the block size for stored. Is it in the i-node of the special file? If that is the case, can we open the special file and store the block size in the proper field? I know that if I gave the file mkfs.c and readfs.c close scrutiny I will find the answers. After all, this is what this OS encourages you to do. But before I head of the the desert without any water, will someone please tell me if I might find a spring along the way. Thanks, rich heffel (rheffel@cs2.wwsu.edu)