filesystem becomming read only

[Tim Rupp]

Thanks Ted, I'll go through that list and try swapping the original
parts with spares that I have around home.

I've run fsck since the problem started occurring and it _has_ found
problems with the filesystem. I don't have the output on hand, but I can
definitely make the filesystem go read-only again. When I do, I can send
another mail with the attached output from the fsck. Maybe it will help
to find the problem.

I'll also try the LKML and Ubuntu forums.

Thanks a lot!
-Tim

Theodore Tso wrote:
> On Sun, Jan 28, 2007 at 04:38:12PM -0600, Tim Rupp wrote:
>> I'm looking for advice/help in tracking down a problem with a new system
>> I've purchased.
>>
>> I have a beige box server with a Gigabyte GA-M51GM-S2G motherboard. It
>> has the nVidia MCP51 SATA controller with 3 250 gig Western Digital hard
>> drives attached to it.
>>
>> It seems that when doing a considerable amount of file writing, the
>> filesystem will become read-only. See attached dmesg output.
> 
> According to the dmesg output, the filesystem is getting remounted
> read-only because the kernel detected an inconsistency in the block
> allocation bitmaps.  Basically, a block that was in use and getting
> freed (due to a file getting deleted) was found to be already marked
> as not in use in the block bitmap.  This is very dangerous, since a
> corrupted block allocation bitmap can result in data loss when a block
> gets used by two different files, and the contents of part of the
> first file gets overwritten by the second.  Hence, ext3 remounted the
> filesystem read-only in order to protect your data from getting (more)
> corrupted.
> 
> The question then is why is this happening.  If you run e2fsck and it
> finds nothing wrong, then that means it was the in-core memory that
> was corrupted --- so the data was correct on disk, but when it was
> read from disk to memory, it had gotten corrupted somehow (another
> good reason for ext3 to mark the filesystem read-only; to prevent the
> corrupted data from getting written back to disk).
> 
> In any case, given that you've checked the memory, it does rather seem
> to narrow it down to either SATA cables, the disk drives, or the SATA
> controller, roughly in that order of probability.  The SATA cables are
> probably the cheapest to try replacing first.  I suppose there is a
> chance that there it's a hardware device driver or kernel issue.  You
> might want to ask on LKML or on the Ubuntu support forums if there are
> any known issues wit the nVidia SATA controller driver.
> 
> Good luck,
> 
> 						- Ted
>