Was there anything in the logs at all? There should be, if the
filesystem was remounted read-only.
> The interesting fsck errors this time were:
> 245782 was part of the orphaned inode list FIXED
> 245792 was part of the orphaned inode list FIXED
> 245797...
>
> 245782,245792 don't exist according to ncheck.
That's not surprising. What this means is that those inodes were
deleted, but since some process still had a file descriptor open for
that inode, it was placed on the orphaned inode list. But the
directory entry would have already been removed, which is why ncheck
couldn't find an associated pathname. The e2fsck error message simply
states that these inodes had a dtime which was small enough that it
was probably the next entry on the orphaned inode linked list, these
inodes weren't actually on the list. At a guess, this probably
happened when an error was noted in the filesystem, and the filesystem
was forcibly put into the read-only state. That probably arrested
some transactions which were not fully completed, and would explain
these sorts of fsck errors.
The real question is what was the original error that caused the ext3
filesystme to decide it needed to remount the filesystem read-only.
That should be in your logs, since calls to ext3_error should always
cause printk's explaining what the error was to be sent to the logs.
The filesystem wouldn't happen to be running close to full either on
the number of blocks or the number of inodes, would it? There's a bug
in ext3 (for which Stephen has already posted bug fixes to be applied
to the 2.4.20-preX kernels) where an running out of blocks or inodes
is being erroneously flagged as a filesystem corruption error, which
would mount the filesystem read-only.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/