grahams@ausonics.OZ (Graham Stoney) (07/13/88)
Could someone please explain how the /dev block special files are attributed
with a size?. For example, /dev/fd0 has a size of 360k; but how did it get it?
mknod(2) has no way of specifying a size; in fact, if you rm /dev/fd0 then
mknod it again with the same major and minor device numbers, it loses its
size. How was it created in the first place?.
Thanks,
Greyham
--
* Greyham Stoney: grahams@ausonics.oz - Ausonics Pty Ltd, Lane Cove.
* (Time to PARTY!!!) greyham@utscsd.oz - The Uni of Technology, Sydney.
* The views expressed may or may not be the views of my Uni or Employer.
* (I don't know... I didn't ask them...)rmtodd@uokmax.UUCP (Richard Michael Todd) (07/18/88)
In article <13@ausonics.OZ> grahams@ausonics.OZ (Graham Stoney) writes: >Could someone please explain how the /dev block special files are attributed >with a size?. For example, /dev/fd0 has a size of 360k; but how did it get it? >mknod(2) has no way of specifying a size; in fact, if you rm /dev/fd0 then >mknod it again with the same major and minor device numbers, it loses its >size. How was it created in the first place?. The only way to create a block-special-file with a size is to specify it in the prototype file given to mkfs when the system is created. The required line in the prototype file looks like this: fd0 b--644 2 1 2 0 360 name mode uid gid maj/min size in KB As you saw, mknod(2) cannot specify the size when the special-file is created. The whole idea of block-special file *having* a size is unique to MINIX; no other Unix variant has it. It isn't terribly clear to me that it's all that useful to have. I suppose if you were terribly interested (and willing to risk major havoc to your filesystem) you could write a program to add a size value to an inode created with mknod(2); it obviously requires mucking around with the raw device on which the filesystem in question is stored and directly fiddling with the inode fields yourself (yecch). -- Richard Todd Highly Dubious Domain: rmtodd@uokmax.ecn.uoknor.edu USSnail:820 Annie Court,Norman OK 73069 Fido:1:147/1 UUCP: sun!texsun!uokmax!rmtodd, at least for now... "MSDOS is a Neanderthal operating system" - Henry Spencer
ast@cs.vu.nl (Andy Tanenbaum) (07/19/88)
In article <13@ausonics.OZ> grahams@ausonics.OZ (Graham Stoney) writes: >Could someone please explain how the /dev block special files are attributed >with a size?. mkfs does it. It's the only way. This is the only way FS can tell when end of file has been hit on a device. Andy Tanenbaum (ast@cs.vu.nl)
Leisner.Henr@xerox.com (marty) (07/22/88)
I've had problems with sizes on block special devices when I got my Minix 1.1. My mkfs didn't work on my hard disk. Essentially I patched fs to issue read/write requests to the device driver and let it fail instead of detetecting seek offsets with respect to block special sizes (which I'm not sure how fs got them in the first place). I'm not convinced the problem has been resolved to my satisfaction. I'll see what Andy's doing in 1.3. I agree the sizes on block special devices aren't very useful (and if anything seemed to cause problems). marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: nsc!nscimg!amps!marty, hplabs!parcvax!leisner
Leisner.Henr@xerox.com (marty) (07/22/88)
Andy, you say: mkfs does it. It's the only way. This is the only way FS can tell when end of file has been hit on a device. So where does FS get the size? I had a headache with 1.1 trying to run mkfs on my hard disk. Eventually what I did was remove size checks on block special devices and let the device driver break if it can't seek. Seems reasonable. From my current working version (quasi-protected mode 1.2): minix/fs/read.c in read_write() ... position = f->filp_pos; if (position < (file_pos) 0) return(EINVAL); rip = f->filp_ino; f_size = rip->i_size; r = OK; cum_io = 0; virg = TRUE; mode_word = rip->i_mode & I_TYPE; #ifdef ORIGINAL if (mode_word == I_BLOCK_SPECIAL && f_size == 0) f_size = MAX_P_LONG; #else if(mode_word == I_BLOCK_SPECIAL) f_size = MAX_P_LONG; #endif I have no idea where rip->i_size got initialized to something meaningful for hard disk partitions, but the number did not make sense. Off the boot disk , it certainly wasn't 0. This fix allowed me to make hard disk partitions on my genuwine IBM PC AT (I initially thought mkfs was broken but the above code makes the difference. What happens is rw_chunk fails eventually when the device driver rejects the request. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: nsc!nscimg!amps!marty, hplabs!parcvax!leisner
steve@basser.oz (Stephen Russell) (07/23/88)
In article <3424@louie.udel.EDU> Leisner.Henr@xerox.com (marty) writes: >Essentially I patched fs to issue read/write requests to the device driver and >let it fail instead of detetecting seek offsets with respect to block special >sizes (which I'm not sure how fs got them in the first place). From the incore inode for a /dev/* file. >I'm not convinced the problem has been resolved to my satisfaction. I'll see >what Andy's doing in 1.3. >I agree the sizes on block special devices aren't very useful (and if anything >seemed to cause problems). >marty Agreed. The drivers know the size of the device, because it is hardcoded. Alternatively, they could work it out from info in the superblock. The best solution would be to add device request messages that allow FS to interrogate the device about its size. steve