I disagree with your statement concerning statistics. Given that there
are reports of both working and non-working systems an equipment matrix
(which in my opinion is not statistics) may show the subtle differences
between the two cases.
I have now tested 2.1.106 on three very different Linux/Intel boxes
and do not have the problem that you are reporting.
>
> If corruption only occurs when disks are dismounted, which is what it
> seems, then you can rule out drivers and physical devices. These
> things don't know why a write occurred --many writes occur during
> normal operation over many hours of use.
I would not be so quick to rule out drivers and physical devices.
I would also not rule out the possiblity of "strangeness" happening
during shutdown from various rc scripts running.
>
> The ext2 file systems are cached. It is important that everything that
> was buffered gets written to the physical device when it is dismounted.
> It looks as though some cached inode data was not written. It also
> looks as though this problem occurs when a greater amount of virtual RAM
> is available because a swap file is installed.
>
> There is more physical RAM available for caching when a swap file is
> installed. There will probably be more dirty inodes cached under these
> conditions. This is probably why the problem occurs when a swap file
> is installed.
Of the three machines all have 64 MB of RAM, all have multiple swap
partitions, and all swap partitions of the maximum size possible.
If having a swap file is the alleged cause of the problem, having
multiple swap partitions should show some evidence of filesytem
corruption.
>
> What needs to be done, is a check of the fs-cache code has to be made
> to see if there is a "sneak-path" that could prevent all the cached data
> from being written to the device during the dismount operation. A hint
> of where to look is in the evidence about the installed swap file.
Please see above concerning swap files.
Your theory would be valid if everyone was experiencing filesystem
corruption
which is not the case. There are at least four reported cases of people
running
2.1.106 and not having the reported problem.
That would seem to imply that there is something different in the
configurations
of working and non-working systems as I have stated before.
>
> There are at least two experts on the ext2 file-system. I am pretty
> sure that at least one is reviewing the reported problem. In the
> meantime, including the '-f' option in the startup script that
> mounts file-systems after a check, may prevent a creeping problems
> that eventually cause errors that can't be readily repaired.
I am not about to force an fsck on my systems when there is no
physical evidence showing that that is necessary.
>
> Cheers,
> Dick Johnson
-- Terry L. Ridder Blue Danube Software (Blaue Donau Software) "We do not write software, we compose it."When the toast is burnt and all the milk has turned and Captain Crunch is waving farewell when the Big One finds you may this song remind you that they don't serve breakfast in hell ==Breakfast==Newsboys
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu