jtn@potomac.ads.com (John T. Nelson) (01/30/89)
A similar question is why does it take so long for the NeXT to boot? I timed it... it takes exactly 5 minutes and 10 seconds and I doubt much of that was fsck time although I could be wrong... One reason it takes so long to boot might be that the object oriented window stuff takes that long to be created, thus it isn't kernel boot time at all but rather the amount of time taken to build the window interface. Thus the time it takes to launch applications might be due to the time it takes to build objects and set up the window interface for that particular application. Just a guess...... -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611 "The only thing more useless than a Faberge' egg is a coffee table picture book about Faberge' eggs"
carter@sloth.gatech.edu (Carter Bullard) (01/31/89)
In article <7554@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: > > >A similar question is why does it take so long for the NeXT to boot? I >timed it... it takes exactly 5 minutes and 10 seconds and I doubt much >of that was fsck time although I could be wrong... > Unfortunately, it is mostly fsck. If you press the command key and the back quote key at the same time, you'll get a mach window asking if you really want to reboot. type y and, if it gives you a NeXT> prompt, type bsd (for boot off of the sd drive). you'll see whats going on when you boot. Carter Bullard School of Information & Computer Science, Georgia Tech, Atlanta GA 30332 uucp: ...!{decvax,hplabs,ihnp4,linus,rutgers}!gatech!carter Internet: carter@gatech.edu
johnl@ima.ima.isc.com (John R. Levine) (01/31/89)
In article <7554@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >A similar question is why does it take so long for the NeXT to boot? I >timed it... it takes exactly 5 minutes and 10 seconds and I doubt much >of that was fsck time although I could be wrong... It's mostly fsck time. If you get into the ROM monitor, you can give the "p" command and turn on verbose booting, so it says the same stuff while booting that any other Unix system does. (The spinning disk is cute, but not very informative.) It seems usually to assume that the disk might be dirty, and so does a full fsck. If I shut down with /etc/halt, it usually but not invariably will skip the long fsck and boots a lot faster. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 { bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something You're never too old to have a happy childhood.
chari@killer.DALLAS.TX.US (Chris Whatley) (01/31/89)
In article <7554@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >One reason it takes so long to boot might be that the object oriented >window stuff takes that long to be created, thus it isn't kernel boot >time at all but rather the amount of time taken to build the window >interface. >Thus the time it takes to launch applications might be due to the time >it takes to build objects and set up the window interface for that >particular application. I'm pretty sure that you are incorrect here. If you do a verbose boot, you will see thatecking the disks takes an enormous chunk of that 5 minutes. Also, in the release notes, it says to logout and log-in as 'exit' every once in awhile. This, I beleive, relaunches the Window server as a kludge for garbage collection Chris -- -------------------------------------------------------- INET: chari@killer.DALLAS.TX.US | BIX: chari UUCP: {anywhere}!killer!chari | -- CI$: 71370,1654 | Phone: 512/453-4238
gillies@p.cs.uiuc.edu (02/03/89)
Why isn't it possible to do the fsck in the background? Couldn't just some *core* set of files (swap files, critical demon programs) be checked, then the rest of the filesystem check could go on in the background, after boot-up? If a problem was found, some sort of panic or system interruption could happen. Don
dave@whoops.celerity (Dave Smith) (02/13/89)
In article <116900004@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >Why isn't it possible to do the fsck in the background? Couldn't just >some *core* set of files (swap files, critical demon programs) be >checked, then the rest of the filesystem check could go on in the >background, after boot-up? If a problem was found, some sort of panic >or system interruption could happen. Unix (and, by extension, Mach, I suppose) believes that a file system is consistent whenever it is mounted. If it should find something wrong with a filesystem it will panic and crash. It's very difficult to fix a file system while it is mounted since a user-level program such as fsck will not have access to the internal buffers of the kernel and won't be able to tell if the filesysytem is inconsistent or if the kernel just hasn't written everything out to disk yet. This is a very good reason for not running fsck on a mounted filesystem since it can make a very nasty mess in its attempts to set things right. One possibility for you to try is to fsck your main filesystems, then have a background process that fsck's, then mounts each of your other filesystems. This is doable, but could be almost as annoying as waiting for fsck to finish on everything if the files you use often are spread across several disks. David L. Smith FPS Computing, San Diego ucsd!celerity!dave "Repent, Harlequin!," said the TickTock Man