jhd%maths.bath.ac.uk@nss.cs.ucl.ac.uk (James Davenport) (01/19/89)
In Volume 7, Issue 102, message 11 of 18, Scott Menter says > Well, this has been said before, but the point is that /usr should be > mounted read-only under 4.x. I buy this argument for clients (in fact, I do the same already under SUNos 3.x). BUT, on the server I mount it r/w because I typically make 1/2 (one or two) edits a week to it: adding to /usr/etc/printcap ot termcap or updating shell scripts in /usr/local/bin or ... I don't run 4.0 (yet:-)) - what's the argument that says /usr should be r/o on the server? [[ As I recently found out, you need it even to boot single user, since most of the executables are on /usr (for example, /bin is a symlink to /usr/bin!) as well as the shared library. If it is mounted r/o, then a crash that doesn't even have a chance to sync (such as a power outage or a "L1-A" followed by "b") won't leave the partition in an inconsistent state. Of course, if you aren't writing to it anyway, it probably doesn't matter. --wnl ]] James Davenport jhd@uk.ac.bath.maths
clyde@cs.utexas.edu (Head UNIX Hacquer) (01/19/89)
Under 4.X most programs in /usr/* are DYNAMICALLY LINKED and so cannot be used unless /usr is mounted so that /usr/lib/ld.so and the /usr/lib/libc.s?.* files are available. If the 'file foobar' command says: foobar: xxxxxx demand paged dynamically linked executable then /usr/lib MUST be available for 'foobar' to run. There are some executables in /usr/etc which are statically linked, and those can be copied into /etc or /sbin. However, practically EVERYTHING in /bin (really /usr/bin) is dynamically linked, so they cannot run 'standalone.' Now what we could use is a a.out munger to make a statically linked executable out of a dynamically linked one... [[ Seriously....it really is needed! Try setting up an anonymous FTP area under 4.0. You either need to make sure the shared library is also accessible in the chroot-ed area, or copy the executable for "ls" from a 3.x machine! --wnl ]] Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas clyde@emx.utexas.edu; ...!cs.utexas.edu!ut-emx!clyde
rayan@ai.toronto.edu (Rayan Zachariassen) (01/25/89)
> If it is mounted r/o, then a > crash that doesn't even have a chance to sync (such as a power outage or a > "L1-A" followed by "b") won't leave the partition in an inconsistent > state. Of course, if you aren't writing to it anyway, it probably doesn't > matter. --wnl We had a series of Very Bad crashes that would cause the disk blocks under the disk heads at the time of the crash to be nulled. For a while, every 2-3 days we would lose root, /usr, /var, /tmp, and two to five other partitions depending on the system activity at the time of the crash (that tends to happen when the filesystem root inode and a few hundred others get stomped on). We are very grateful we had a way of booting that system that didn't use its main disks, and that we had a stable twin machine right next to it so we could dd /usr across the net when it got trashed. The point is, just because software people think a partition being read-only means it won't be corrupted, doesn't mean it won't be corrupted (insert snide remark about hardware people :-). I wonder how the robust filesystems of the future will deal with failures that ``can't happen'' according to the software semantics or ``improbable'' hardware failures. Having to trash an entire partition, just because all copies of some piece of data goes bad, shouldn't be acceptable in that context. Paranoia is good for you! rayan [[ Being a system manager type, I completely agree with you about paranoia. A speck of dust that gets wedged between the flying head and the disk surface really isn't going to care much about the fact that you have that partition mounted read-only. But I was referring more to the fact that with a partition mounted read-only the cache in the kernel will never be inconsistent with the disk contents. The most common cause of trashed file systems is an unflushed cache (because Unix's cache is not write-through). That means that *any* crash (not just those caused by the disk drivers) can corrupt the disk if the kernel never gets the chance to "sync" the disks. By the way, has any vendor ever considered adding write-through to Unix's file system cacheing code? (Now I'll probably get dozens of messages telling me that it was put in V5R1 500 years ago and what rock did I just crawl out from under and I should stop putting these editorial comments in if they're just going to be wrong all the time :-). --wnl ]]