Ext3 corruption on a drive

Bug #65815 reported by MistaED
This bug report is a duplicate of:  Bug #53102: Ext3 filesystem corruption - data loss. Edit Remove
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Incomplete
Undecided
Unassigned
linux-source-2.6.17 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Hello, I have recently upgraded from dapper to edgy and currently experiencing severe problems with one of my drives. I am using the 32-bit ubuntu version. This is my current setup:

Motherboard: ASUS K8V-SE Deluxe
CPU: 3200+ Athlon64 s754 newcastle
Ram: 1GB
HDDs: 320gb SATA /dev/sda, 80gb PATA /dev/hda, 200gb PATA /dev/hdb

My /etc/mtab:
/dev/sda3 / reiserfs rw,notail 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
/sys /sys sysfs rw,noexec,nosuid,nodev 0 0
varrun /var/run tmpfs rw,noexec,nosuid,nodev,mode=0755 0 0
varlock /var/lock tmpfs rw,noexec,nosuid,nodev,mode=1777 0 0
procbususb /proc/bus/usb usbfs rw 0 0
udev /dev tmpfs rw,mode=0755 0 0
devshm /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
lrm /lib/modules/2.6.17-10-386/volatile tmpfs rw 0 0
/dev/sda5 /home ext3 rw 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
/dev/hdb1 /media/hdb1 ext3 rw 0 0

My /etc/fstab:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda3 -- converted during upgrade to edgy
UUID=561dcfca-dca7-48e6-bd5a-489e143c770f / reiserfs notail 0 1
# /dev/sda5 -- converted during upgrade to edgy
UUID=764d80be-9f65-44cb-9e61-edf1abee9832 /home ext3 defaults 0 2
# /dev/hdb1 -- converted during upgrade to edgy
/dev/hdb1 /media/hdb1 ext3 defaults 0 2
# /dev/sda2 -- converted during upgrade to edgy
UUID=7d544689-ac59-4436-bbea-32a3f3286f1b none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/hdd /media/cdrom1 udf,iso9660 user,noauto 0 0
#/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

/dev/hda is windows and I am currently not mounting it with ubuntu
I modified the UUID for /media/hdb1 to /dev/hdb because when mounting it couldn't find the drive half the time. (Sorry but I foolishly took it out instead of just commenting out the UUID string, not sure how to get it back now).

Now the problem I am having is /dev/hdb1 is currently having errors here and there. Some days I can boot up and it would mount fine. Sometimes it would only mount as read-only, and other days it would display my filesystem all over the place in an inconsistent manner. When fsck.ext3 is run, it keeps picking up inode errors all the time, and I don't know why. The superblock is also getting corrupted on a regular basis and I am using block 32768 all the time to fsck.ext3 the drive. I used some SMART tools to check if the drive is dying but it seems to be all fine.

Sorry if udev is the wrong package to post this, it's either udev, ext3 or something else. Maybe teardown is not unmounting it properly? It's odd how it only seems to affect one drive. Once the drive is clean and it mounts, it works perfectly until the next time it happens when I boot up. Dapper handled the drive fine, so I doubt the hard drive is at fault.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Bounce to the kernel, but tbh, sounds more like your drive is dying.

Revision history for this message
MistaED (boberfly) wrote :

This isn't looking good at all, my log for today is having problems with my /dev/sda5 now. These two partitions are the only ext3 partitions on my system, as the root fs is reiserfs and it's having to issues what so ever. As far as I know, the sda5 was formatted just like any other standard ext3 format in dapper drake, so it seems odd how edgy is saying the revision is too high. I'm downloading updates today, so we'll see if it still does it after them.

Log of fsck -C -R -A -a
Sat Oct 14 12:41:11 2006

fsck 1.39 (29-May-2006)
/dev/evms/sda5: clean, 144821/35733504 files, 56231814/71451087 blocks
fsck.ext3: Filesystem revision too high while trying to open /dev/hdb1

The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)

/dev/hdb1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

fsck died with exit status 8

Sat Oct 14 12:41:12 2006
----------------

Revision history for this message
Tero Karvinen (karvinen+launchpad) wrote :

Similar bugs:
Bug #65815 Ext3 corruption on a drive
Bug #53102 ext3 partitions are getting corrupt more often than they should
Bug #66032 fsck.ext3: Unable to resolve
Bug #118256 ext3 data corruption with kernel 2.6.20-16-generic

Is there anything more serious than massive corruptive data loss? Maybe importance should be raised.

Revision history for this message
Launchpad Janitor (janitor) wrote : This bug is now reported against the 'linux' package

The 18 month support period for Edgy Eft 6.10 has reached its end of life. As a result, we are closing the linux-source-2.6.17 Edgy Eft kernel task. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.