lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (06/01/90)
[ Followups in comp.unix.questions ] summer@atreides.trl.oz.au (Mark Summerfield - Switching) writes: >The problem is that using mount() doesn't add an entry to /etc/mtab, so >other commands (such as df, and umount) don't know about the >filesystem. Which leads me to pose the question: Why does Unix use a file to store mount information? It seems to me that the proper way to determine what's mounted would be to look in the kernel mount tables. It would be trivial to implement a system call to return the information. Anyone know why the "ask the kernel" approach was never taken? -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca Sendmail has been described as the largest program yet created that does absolutely nothing. -- Mr. Protocol
trt@rti.rti.org (Thomas Truscott) (06/01/90)
> Why does Unix use a file to store mount information?
Because it did 90% of the job with 10% of the effort.
Ultrix replaced /etc/mtab with the "getmnt" system call
which has lots of strange parameters.
Much simpler would be to have a "/dev/mtab" special device
which works like "/dev/mem" but only accesses the kernel mount table.
Similarly one might have "/dev/proc".
Just more minor numbers for the basic /dev/mem driver.
Tom Truscottbzs@world.std.com (Barry Shein) (06/03/90)
>Which leads me to pose the question: > > Why does Unix use a file to store mount information? > >It seems to me that the proper way to determine what's mounted would >be to look in the kernel mount tables. It would be trivial to implement >a system call to return the information. Anyone know why the "ask the >kernel" approach was never taken? It goes way back to the early Unix days, V6 on the PDP-11 certainly had /etc/mtab. With a maximum of 64KB for the kernel you made trade-offs, one of Unix's early plus's was how much it used facilities outside the kernel to get things done. Design goals were also compelling. Of course, in this day and age it seems like a minor savings, but you could probably find dozens of things like this to put in the kernel if you looked around. The bloat would start to get real (why not store environment variables in the kernel so children can set parent processes? How about the password/group file? host tables? Heck, everything YP manages? etc etc.) There are a lot of us out there who hope the trend would be quite the other way, more for design reasons than memory concerns. Things in the kernel tend to quickly become immutable in various ways. Putting things in the kernel tends to make innovation impossible unless you're a kernel hacker (and have the sources, time and energy.) Just changing, e.g., the way a few fields in a text file are handled is not very hard if you wanted to extend mount table semantics. What you really want is just a putmountent() library to hide the details of the service, not to redesign Unix to make it easier to write that one library call. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (06/06/90)
>It goes way back to the early Unix days, V6 on the PDP-11 certainly >had /etc/mtab. With a maximum of 64KB for the kernel you made >trade-offs, one of Unix's early plus's was how much it used facilities >outside the kernel to get things done. Design goals were also >compelling. >Of course, in this day and age it seems like a minor savings, but you >could probably find dozens of things like this to put in the kernel if >you looked around. The bloat would start to get real (why not store >environment variables in the kernel so children can set parent >processes? How about the password/group file? host tables? Heck, >everything YP manages? etc etc.) [ and more stuff about saving precious kernel space ] To which Lyndon replies: Barry, the information is *already* in the kernel, inside the mount tables. I was wondering what it was that was being saved by duplicating the kernel information in a file. Tom Truscott's answer was what I expected to hear, but you never know ... :-) BTW - I like the idea of implementing /etc/mtab as /dev/mtab. The big problem I have with /etc/mtab is that it is usually completely out of sync with respect to the contents of the kernel's mount tables (primarily due to NFS failures). In these days of almost-reliable network file systems, I don't think we should be second guessing in user space something as intimately related to the kernel as the mount table. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca Sendmail has been described as the largest program yet created that does absolutely nothing. -- Mr. Protocol
del@thrush.mlb.semi.harris.com (Don Lewis) (06/06/90)
In article <1929@aurora.cs.athabascau.ca> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >BTW - I like the idea of implementing /etc/mtab as /dev/mtab. The big >problem I have with /etc/mtab is that it is usually completely out of >sync with respect to the contents of the kernel's mount tables (primarily >due to NFS failures). In these days of almost-reliable network file >systems, I don't think we should be second guessing in user space something >as intimately related to the kernel as the mount table. It is also hard to keep /etc/mtab up to date, if you boot up single user and your root filesystem is mounted read-only. On the other hand, nfs mounts store hostname:remote path in /etc/mtab, but store a socket address and file handle in the kernel mount table. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901