[lkml]   [1998]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ext2 fs not properly updated upon dismount.
Richard B. Johnson wrote:
> [SNIPPED all]
> Statistics only confuse the issue. Disks are only mounted/unmounted
> using two system calls. If the device was marked as properly dismounted,
> which is what fsck checks and states, then the device was dismounted. You
> don't care about version numbers of mount/dismount/...etc. You also
> don't care about C-runtime libraries. The system-call was executed with
> the proper device name as a parameter. It doesn't make any difference
> how the name got there nor how the call was generated.

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

> 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
which is not the case. There are at least four reported cases of people
2.1.106 and not having the reported problem.

That would seem to imply that there is something different in the
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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.068 / U:0.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site