serious fsck problem

A while back my system didn't get unmounted so I had to fsck

and fsck found a zero dtime Inode and it said it fixed it. But just for
fun I set tune2fs so that my system would force a fsck at every boot.
Now every time I boot up fsck finds 1 or more zero dtime inodes and it
says it repairs them. I set in my scripts for umount to do verbose mode
to make sure the drive was getting unmounted and it is. I also ran the
bad blocks program and it found no bad blocks. I also tried to do a
readonly e2defrag and it says error seeking to end of filesystem. I
checked fdisk to make sure there was no over lapping in partions and
theres not. I just cant figure out why fsck always on every boot finds
zero dtime inodes?

/dev/hdb1  * Start 1 End 1024 Blocks 7741408+   83 Linux
/dev/hdb2          1025  2651        12300120   f  Win95 Ext'd (LBA)
/dev/hdb5          1025  2651        12300088+  b  Win95 FAT32
jmattson20Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jlevieCommented:
Which Linux are you running?

Have you tried booting single user, or better yet from a floppy, and running fsck twice to see if in fact the zero dtime inodes are being repaired (not found on the second fsck)?
0
bernardhCommented:
tune2fs adjusts tunable filesystem parameters on a Linux
second extended filesystem. This utility is destructive that's why it is advised never to use it to change  parameters of a read/write mounted filesystem.
0
jmattson20Author Commented:
I am running linux mandrake 6.1 and kernel version 2.2.13-22mdk. If I go into single user mode and then fsck when I reboot fsck finds NO errors. But when I reboot for the third time then it finds the errors again and so on. And no when fsck found the errors and asked for my maintence password I gave it and went into read only mode. That is when I set tune2fs to check the system every time I boot.
0
jlevieCommented:
Bear with me... I want to make sure we're saying the same thing.

If you boot to single user mode, run fsck and immediately reboot no errors are found.

If you then reboot that instance of the system, the auto-fsck you've configured reports errors. And each succeeding reboot reports errors.

Lets consider what happens in the first case. The file system gets fsck'd and repaired. Since the kernel is running hardly any services and you don't run any other tasks, the file system is essentially static. You call for a reboot and the system goes through it's normal shutdown including unmounting the file system (important point!).

When the system boots this time, there are no errors to report. However, it goes into multi-user mode (which starts lots of services, at least some of which write to the disk). Also you probably login, run an app or two, etc. In other words there's a fair bit of disk activity, including writes.

Now you call for a reboot, which again unmounts the file systems. But, this time when it comes up there are errors.

The filesystem has apparently been cleanly unmounted in both cases, which just means that the kernels in-memory image of the changes to the disk are supposed to have been committed to disk. When there's no significant activity it works, but otherwise it doesn't.

At this point there are entirely too many possibilites. It's possible, though somewhat unlikely, that there's a bug in umount or a bug in the kernel that corrupts the in-memory cache. Most likely such a bug would wreak a lot more havoc and be "well known" by now. It's a bit more likely that there's some problem with your installation or with the hardware (flaky memory, disk controller, drive) that causes the kernel's idea of the file system to not match that on disk, but that also should cause a lot more problems than one (or a few) zero dtime inodes. And finally it could be a benign problem that's been there all along or an artifact of turning on auto-fsck and you are only seeing it because you activated the fsck on every boot.

I happen to use RedHat so I can't exactly duplicate what you're doing to play with it. On Redhat I see that fsck will notice if a file system (other than root) has been marked as "clean" (meaning it had been cleanly unmounted) and immediately terminate. The root file system is a bit of a special case. Even when booted in single user mode it has to be mounted read/write, and it can't be "clean" at that point. If you've installed Linux using a single file system (the default) you really can't tell how it would behave unless you were to boot from a Linux floppy.

I think if it were my system, that I'd re-enable interval checking and keep my backup's up to date (at least for the stuff that a re-install wouldn't create) and see what happens.  
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jmattson20Author Commented:
Well I put back interval checking. When my system boots it does say its clean and I havent had any file corruption problems yet so Ill just have to see what happens
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.