dsg@mbunix.mitre.org (David S. Goldberg) (08/31/89)
We are planning to upgrade our 8600 from Ultrix 2.3 to 3.1 in the very near future. Since version 1.2 we have been using Chris Torek's preen program to make fsck's run faster. With 2.X we started taking advantage of NFS, but always used the 8600 to export filesystems, never importing. Now we want to start importing filesystems as well, and I put some entries in /etc/fstab to mount them. When the system rebooted, preen choked on the NFS filesystem entries (a no such device error). I checked the source, and suspect that it wouldn't be too hard to make preen ignore these entries, but if it's been done before, I'd rather be doing other things (or rather, my boss would rather I be doing other things :-). Has preen ever been modified to work with NFS filesystems. I couldn't even find the original source on uunet. Anyplace else to look? Thanks, Dave Goldberg -------------------------------------------------------------------------- Dave Goldberg ARPA: dsg@mitre.org The Mitre Corporation UUCP: linus!mbunix!dsg MS B020 Bedford, MA 01730 617-271-2460
grr@cbmvax.UUCP (George Robbins) (09/03/89)
In article <66554@linus.UUCP> dsg@mbunix.mitre.org (Goldberg) writes: > > We are planning to upgrade our 8600 from Ultrix 2.3 to 3.1 in the very > near future. Since version 1.2 we have been using Chris Torek's preen > program to make fsck's run faster. I'm not familiar with this preen program, but I owuld point out that DEC has improved the "fsck -p" option so that it doesn't bother with filesystems that are "clean" or haven't been modified since last unmounted. This lets you do a planned shutdown/startup quickly, though after a crash, it's still going to take a while... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
lamy@ai.utoronto.ca (Jean-Francois Lamy) (09/04/89)
grr@cbmvax.UUCP (George Robbins) writes: >I'm not familiar with this preen program, but I owuld point out that DEC has >improved the "fsck -p" option so that it doesn't bother with filesystems >that are "clean" or haven't been modified since last unmounted. This lets >you do a planned shutdown/startup quickly, though after a crash, it's still >going to take a while... Hardly an improvement. I've seen machines do perfectly orderly shutdowns, yet fsck -p discover some inconsistencies after reboot. I've seen two or three successive fscks on the same unmounted file system fix inconsistencies before the file system fsck-ed cleanly twice in a row. We tend to view "guessing" schemes rather dimly around here... Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
grr@cbmvax.UUCP (George Robbins) (09/04/89)
In article <89Sep3.144349edt.2288@neat.cs.toronto.edu> lamy@ai.utoronto.ca (Jean-Francois Lamy) writes: > grr@cbmvax.UUCP (George Robbins) writes: > > >I'm not familiar with this preen program, but I owuld point out that DEC has > >improved the "fsck -p" option so that it doesn't bother with filesystems > >that are "clean" or haven't been modified since last unmounted. This lets > >you do a planned shutdown/startup quickly, though after a crash, it's still > >going to take a while... > > Hardly an improvement. I've seen machines do perfectly orderly shutdowns, yet > fsck -p discover some inconsistencies after reboot. I've seen two or three > successive fscks on the same unmounted file system fix inconsistencies before > the file system fsck-ed cleanly twice in a row. We tend to view "guessing" > schemes rather dimly around here... All depends on your local degree of flakeyness, I guess. Experience here with Ultrix seems to indicate that if you shutdown the system and unmount the filesystems, it'll fsck cleanly. It's still a good idea to force fsck to do it's job once in a while, especially if the system's been up for a couple of months. Haven't had that kind of luck lately, and it tends to check almost everything writable when rebooting after a crash. I didn't too much mind doing fsck's everytime before, but when you start playing with G-byte class drives, it does get kind of tedious. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
chris@mimsy.UUCP (Chris Torek) (09/05/89)
>In article <66554@linus.UUCP> dsg@mbunix.mitre.org (Goldberg) writes: >>We are planning to upgrade our 8600 from Ultrix 2.3 to 3.1 in the very >>near future. Since version 1.2 we have been using Chris Torek's preen >>program to make fsck's run faster. Actually, Fred Blonder wrote the original version of preen. I simply rewrote it and cleaned it up. In article <7817@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >I'm not familiar with this preen program, but I would point out that DEC has >improved the "fsck -p" option so that it doesn't bother with filesystems >that are "clean" or haven't been modified since last unmounted. This is certainly useful, but is a very different thing. What preen does is run `fsck -p' on all disk drives in parallel. `But wait', I hear, `fsck -p already runs in parallel via the pass numbers.' Nope. fsck -p *oozes* in parllel via the pass numbers, unless all your disk partitions take exactly as long to check as all others that have the same pass number. If you have more than one file system per drive, this is almost guaranteed to be false. Preen depends on the disk naming scheme, and assumes that two partitions are on the same physical drive if and only if the device names match except for the partition letter. Thus, /dev/ra0[a-h] are all `the same', but all differ from /dev/ra1[a-h], etc. Except on Encore UMAX systems, I have never seen this assumption violated (and on ours, we un-violated it because we found `/dev/usr' just plain annoying). In any case, preen will be unnecessary in 4.4BSD, where fsck has been modified to use preen's scheduling algorithm instead of the old pass numbers. If Encore intend to keep up with 4.4BSD, they may have to change their naming scheme back.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris