garyc@robbie.acns.nwu.edu (06/04/91)
I have NeXTStep 2.1 running on the Color Station 16/400. I accidentally double
clicked the file "/NextLibrary/References/Webster-Dictionary/Dictionary.nxbf"
which is about 20 megs big. And of course it invoked Preview which was loading
for more than 5 mins. I then used 'Processes' in WorkSpace to kill that
process. A Core dump was generated which was about 3 megs; I deleted it but
I also found out that 6 Megs out of 406 of the hard disk space was gone!??
I then login Root and do the following in the Shell:
/*****************************************************************************/
localhost# fsck
** /dev/rsd0a
** Currently Mounted on /
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=27266 OWNER=root MODE=100644
SIZE=1180 MTIME=Jun 2 20:18 1991
CLEAR? y
UNREF FILE I=61035 OWNER=root MODE=100666
SIZE=9 MTIME=Jun 3 17:12 1991
CLEAR? y
** Phase 5 - Check Cyl groups
BLK(S) MISSING IN BIT MAPS
SALVAGE? y
12310 files, 197509 used, 204744 free (744 frags, 25500 blocks, 0.2% fragmentation)
File system not may not be clean! Run fsck again to clean.
***** FILE SYSTEM WAS MODIFIED *****
***** REBOOT THE SYSTEM (NO SYNC) *****
localhost#
/*****************************************************************************/
I've tried <1> reboot -n.
<2> switch from NMI to mon NeXT> and reboot the system.
<3> Alt-Cmd-* To reset the machine.
<4> run fsck again to clean the File system and then reboot.
<n> ......... many trials + phone calls.
The result remains the same, Everytime I run fsck, it says the same errors. And
the missing 6 Megs never comes back. The file system was never fixed. ---
The buffer cache always rewrited the superblock, I guess, even I specified
the -n (No Sync) or or reboot the system from Mon.
I've been looped around by the NeXT support by asking such questions that few
people ever experienced. Can anyone find me back the lost 6 Megs?
-Gary Chang
NeXT-Mail Addr: garyc@robbie.acns.nwu.edu
E-Mail Addr: garyc@eecs.nwu.edueps@toaster.SFSU.EDU (Eric P. Scott) (06/04/91)
In article <1991Jun4.052732.13192@casbah.acns.nwu.edu> garyc@robbie.acns.nwu.edu writes: > I then login Root and do the following in the Shell: >/*****************************************************************************/ >localhost# fsck Running fsck on a mounted filesystem is a sure-fire way to trash it. The only exception is for the root file system in single- user mode where an immediate reboot-without-sync occurs immediately thereafter. -=EPS=-
zack@magus.UUCP (Zacharias_Beckman) (06/13/91)
In article <676362343.59@egsgate.FidoNet.Org> Unknown@f98.n250.z1.FidoNet.Org (Unknown) writes: > > I then login Root and do the following in the Shell: >/*****************************************************************************/ >localhost# fsck >** /dev/rsd0a >** Currently Mounted on / > > ... etc ... > >***** FILE SYSTEM WAS MODIFIED ***** I hate to tell you this -- but I will, since it may save you great headaches in the future. According to NeXT (reliable lines internally, as we have a good relationship with them) you MUST NEVER, EVER, EVER run fsck manually. I did once upon a time. Had to rebuild the machine eventually. Now, I'm not sure that this applies to single user mode. But, even on a generic Unix system it's not a good idea to run fsck while booted multi-user. I wish you luck in not having to rebuild! As for the missing six megs; I suspect that it was simply your swap cache expanding or some such thing. Happens over time. I can't imagine why you didn't get it back later, but then there is no telling if the file system has been corrupted. -- Zacharias J. Beckman | To be "matter of fact" about the world is to Lower Code Dweller | blunder into fantasy -- and dull fantasy at that, Boss Logic Inc. | as the real world is strange and wonderful. zack@bosslogic.com | --- Lazarus Long, by R. A. Heinlen
shanega@athena.mit.edu (Shane G. Artis) (06/13/91)
In article <202@magus.UUCP> zack@magus.UUCP (Zacharias_Beckman) writes: >I hate to tell you this -- but I will, since it may save you great headaches >in the future. According to NeXT (reliable lines internally, as we have a >good relationship with them) you MUST NEVER, EVER, EVER run fsck manually. I >did once upon a time. Had to rebuild the machine eventually. > >Now, I'm not sure that this applies to single user mode. But, even on a >generic Unix system it's not a good idea to run fsck while booted multi-user. >I wish you luck in not having to rebuild! Could you expand and clarify these statements a bit? Fsck is an important tool, and I have used it in the past on my NeXT. What exactly did NeXT say about its use, and what should we do instead of using it when it becomes necessary? Thank-you, Shane
louie@sayshell.umd.edu (Louis A. Mamakos) (06/13/91)
fsck on the NeXT is just like fsck on any other [normal] BSD based UNIX systems. Its not so much the case of being in multi-user mode or not, but if the file system is currently mounted. You cannot use it to fix a broken file system while it is mounted. If you have a damaged file system, you should unmount it first (if its not the root file system) and then run fsck on it. After fsck has repaired it, you can then manually remount it. There is no way to unmount the root file system, which is why you can only repair it while in single user mode when you can easily halt the system without syncing the in-memory state of the file system to the disk. If fsck has modified the root file system, then you *must* halt the system **WITHOUT** syncing the file system. For example, /usr/etc/halt -n will do this. Please remember, while you're running as root, you have the potential to do a great deal of damage. If you are not completely sure what a command does, especially dangerous ones in /etc or /usr/etc, then you shouldn't run them as root. RTFM, or let the system "fix" itself if it can when it reboots. louie