On Thu, Sep 26, 2002 at 12:08:54PM -0700, Ryan Cumming wrote:> On September 26, 2002 08:42, Theodore Ts'o wrote:> > Hmm... I just tried biult 2.4.19 with the ext3 patch on my UP P3> > machine, using GCC 3.2, and I wasn't able to replicate your problem.> > (This was using Debian's gcc 3.2.1-0pre2 release from testing.)> The whole GCC 3.2 thing was a red herring. Although it ran stable for a few > hours last night (cvs up, compiled a kernel, etc), the filesystem was once > again read-only when I came to check my mail this morning.

Was there anything in the logs at all? There should be, if thefilesystem 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 weredeleted, but since some process still had a file descriptor open forthat inode, it was placed on the orphaned inode list. But thedirectory entry would have already been removed, which is why ncheckcouldn't find an associated pathname. The e2fsck error message simplystates that these inodes had a dtime which was small enough that itwas probably the next entry on the orphaned inode linked list, theseinodes weren't actually on the list. At a guess, this probablyhappened when an error was noted in the filesystem, and the filesystemwas forcibly put into the read-only state. That probably arrestedsome transactions which were not fully completed, and would explainthese sorts of fsck errors.

The real question is what was the original error that caused the ext3filesystme to decide it needed to remount the filesystem read-only.That should be in your logs, since calls to ext3_error should alwayscause 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 onthe number of blocks or the number of inodes, would it? There's a bugin ext3 (for which Stephen has already posted bug fixes to be appliedto the 2.4.20-preX kernels) where an running out of blocks or inodesis being erroneously flagged as a filesystem corruption error, whichwould mount the filesystem read-only.