johnl@n3dmc.UU.NET (John Limpert) (04/03/89)
I recently ran into a bunch of problems with fsck and my news filesystem. It started out with the filesystem getting really messed up with multiply allocated disk blocks. After many iterations of running fsck most of the problems were fixed. One problem remains, fsck seems to get confused about the contents of the free list. If I run a normal fsck, i.e. 'fsck /dev/rdsk/0s3', fsck says there are 100 DUP blocks in the free list, offers to rebuild the free list and comes up with a bogus number of free blocks on the filesystem. Running 'fsck -f /dev/rdsk/0s3' seems to work correctly and build a good free list. This only started to happen recently. When I setup the hard disk configuration on my system I was careful to keep partitions smaller than 130000 blocks, however the news partition was mkfs'd with many more inodes than the default value. My guess is that the large number of active inodes is overflowing some table in fsck and corrupting other data. This all sounds like some problems that had been previously reported on comp.unix.microport. Am I on the right track? -- John A. Limpert UUCP: johnl@n3dmc.UUCP, johnl@n3dmc.UU.NET, uunet!n3dmc!johnl
dave@micropen (David F. Carlson) (04/04/89)
In article <637@n3dmc.UU.NET>, johnl@n3dmc.UU.NET (John Limpert) writes: > > I recently ran into a bunch of problems with fsck and my news > filesystem. It started out with the filesystem getting really > messed up with multiply allocated disk blocks. > ... > This all sounds like some problems that had been previously reported > on comp.unix.microport. Am I on the right track? > -- > John A. Limpert > UUCP: johnl@n3dmc.UUCP, johnl@n3dmc.UU.NET, uunet!n3dmc!johnl A couple of notes: 1). fsck has several bugs. Be very careful. 2). SVR3.0 has a file system bug that shows up when a fs runs out of blocks or inodes. Fsck(1) cannot fix it. mkfs(1) does. Tough luck! 3). In general, putting /usr/spool on a separate partition is a "good" thing since it is liable to overflow and other /usr functions might be compromised. I go so far as to mount a seperate file system for /usr/spool/news, as mine has found the SV file system full bug several times due to overflow on weekends. This I did before I was even on microport but it becomes even more imperative under SVr3.0. 4). Don't put /usr, /usr/spool and /usr/spool/news on the same partition and complain here about trashed file systems: you have been warned! -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
rsj@wa4mei.UUCP (Randy Jarrett WA4MEI) (04/04/89)
In article <637@n3dmc.UU.NET> johnl@n3dmc.UU.NET (John Limpert) writes:
++
++I recently ran into a bunch of problems with fsck and my news
++filesystem. It started out with the filesystem getting really
++messed up with multiply allocated disk blocks. After many iterations
++of running fsck most of the problems were fixed. One problem
++remains, fsck seems to get confused about the contents of the
++free list. If I run a normal fsck, i.e. 'fsck /dev/rdsk/0s3', fsck
++says there are 100 DUP blocks in the free list, offers to rebuild
++the free list and comes up with a bogus number of free blocks
++on the filesystem. Running 'fsck -f /dev/rdsk/0s3' seems to
++work correctly and build a good free list. This only started to
++happen recently. When I setup the hard disk configuration on my
++system I was careful to keep partitions smaller than 130000 blocks,
++however the news partition was mkfs'd with many more inodes than
++the default value. My guess is that the large number of active inodes
++is overflowing some table in fsck and corrupting other data.
++This all sounds like some problems that had been previously reported
++on comp.unix.microport. Am I on the right track?
++
++--
++John A. Limpert
++UUCP: johnl@n3dmc.UUCP, johnl@n3dmc.UU.NET, uunet!n3dmc!johnl
I think that you will find that fsck on microport has that problem with any
filesystem that is greater than ~80000 blocks. This is the size that I had
some problems with and I wouldn't be supprised if it turned out that the
magic number was something in the area of 64000. Once the problem starts
everytime you run fsck you compound the problem. I let fsck run to the point
that it asks if I want to rebuild the free chain and then answer no. I then
run it with the -f option to let it straighten everything up.
--
Randy Jarrett WA4MEI
UUCP ...!gatech!wa4mei!rsj | US SNAIL: P.O. Box 941217
PHONE +1 404 493 9017 | Atlanta, GA 30341-0217