Very Computer

We have an old Sparc 5 clone running Solaris 2.5.1.  When I run fsck
on the root file system, it looks like this:

# fsck /
** /dev/rdsk/c0t3d0s0
** Currently Mounted on /
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=3  OWNER=root MODE=40700
SIZE=8192 MTIME=Oct  1 10:41 1997  COUNT 2 SHOULD BE 4
ADJUST? y

** Phase 5 - Check Cyl groups
4174 files, 139379 used, 25726 free (566 frags, 3145 blocks,  0.3% fragmentation)

No matter how many times I ask it to adjust, the error is still there,
even after a reboot.  Is this a sign of a bad disk?  Is there some way
to figure out which file is causing the problem?
--
*   Patrick L. Nolan            (650)723-0133                 *
*   W. W. Hansen Experimental Physics Laboratory (HEPL)       *
*   Stanford University                                       *

Quote:> We have an old Sparc 5 clone running Solaris 2.5.1.  When I run fsck
> on the root file system, it looks like this:

> # fsck /
> ** /dev/rdsk/c0t3d0s0
> ** Currently Mounted on /

You should umount root file system (it means boot from cd-rom, and then
run fsck on not-mounted FS) and repair it.

Quote:> ** Phase 4 - Check Reference Counts
> LINK COUNT DIR I=3  OWNER=root MODE=40700
> SIZE=8192 MTIME=Oct  1 10:41 1997  COUNT 2 SHOULD BE 4
> ADJUST? y

--
andrei

Quote:>We have an old Sparc 5 clone running Solaris 2.5.1.  When I run fsck
>on the root file system, it looks like this:

># fsck /
>** /dev/rdsk/c0t3d0s0
>** Currently Mounted on /
>** Phase 1 - Check Blocks and Sizes
>** Phase 2 - Check Pathnames
>** Phase 3 - Check Connectivity
>** Phase 4 - Check Reference Counts
>LINK COUNT DIR I=3  OWNER=root MODE=40700
>SIZE=8192 MTIME=Oct  1 10:41 1997  COUNT 2 SHOULD BE 4
>ADJUST? y

>** Phase 5 - Check Cyl groups
>4174 files, 139379 used, 25726 free (566 frags, 3145 blocks,  0.3% fragmentation)

>No matter how many times I ask it to adjust, the error is still there,
>even after a reboot.  Is this a sign of a bad disk?

More likely the result of running fsck against a mounted filing system...

Quote:>                                                     Is there some way
>to figure out which file is causing the problem?

Sure: it tells the the inode number, so you could do "find / -mount -inum 3 -ls".
You will almost certainly find it is /lost+found. If so, clean it out before
running fsck again. [And use -n unless you do it in single-user mode, preferably
with / mounted read-only at the time.]

Chris Thompson
Email: cet1 [at] cam.ac.uk

Inode 3 is alway s the root inode of a filesystem.

--



URL:  http://www.fokus.gmd.de/usr/schilling    ftp://ftp.fokus.gmd.de/pub/unix

[...]

Quote:

>Inode 3 is alway s the root inode of a filesystem.

Inode 2 is always the root directory inode of UFS filing systems. There's no
such constraint for filing systems in general; try ld -di /tmp !

Inode 3 is created as the lost+found directory by mkfs_ufs, but it's possible
to remove it: fsck will recreate lost+found if necessary, but not always at
inode 3. [This has been a buggy area of fsck in the past, though. In fact, the
persistent reports about bad link counts for inode 3 may well be the *result*
of lost+found not being at inode 3 any longer, now I come to think about it.]

Chris Thompson
Email: cet1 [at] cam.ac.uk

Quote:>[...]
>such constraint for filing systems in general; try ld -di /tmp !

Or rather, "ls -di /tmp". Sorry about that...

Chris Thompson
Email: cet1 [at] cam.ac.uk