Unexpected inconsistency on ext3 filesystem

I upgraded from 11.4 => 12.2
My /home is a second harddisk with an ext3 filesystem

Since the upgrade I get errors when booting:


file-recovery-flag is clean but journal has data
/dev/sdb1 Run journal anyway UNEXPECTED INCONSISTENCY. Run fsck manually (i.e. without -a or -p option)

I recreated the partitioned but the problem remains.

When I mount /home manually, I don’t have any problem.

My /etc/fstab


/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part3 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part7 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part5 /                    ext3       acl,user_xattr        1 1
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part8 /opensuse11_4        ext3       defaults      1 1
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part10 /home2                ext4       defaults              1 2
/dev/disk/by-id/ata-SAMSUNG_HD250HJ_S0URJ1KQ501192-part1 /home ext3 noauto 1 2

When I change noauto into defaults the problem occurs again.

Did you perform a file system check, as the message suggests? Some inconsistency has been detected on the file system on /dev/sdb1, it has to be checked and fixed before it’s reliable again.

I would also request the output from a terminal fdisk -l (-l is a -L, but must be lower case) command to determine what partition is /dev/sdb1:

sudo /sbin/fdisk -l

Thank You,

Funny thing I didn’t see the first time: you have 2 swap partitions mounted.

That happens/ can happen when you install more than one Linux distro or version. You only need one swap file, but all of them get mounted and the space added together by the default openSUSE install.

Thank You,

I ran fsck /dev/sdb1. I had no choice.
It reported no errors

Output from fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00047f42

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    41945714    20972826    c  W95 FAT32 (LBA)
/dev/sda2        41945715    83891429    20972857+   c  W95 FAT32 (LBA)
/dev/sda3        83891430    83907494        8032+  82  Linux swap / Solaris
/dev/sda4   *    83907495   976768064   446430285    f  W95 Ext'd (LBA)
/dev/sda5        83907558   125853209    20972826   83  Linux
/dev/sda6       125853273   335581784   104864256   83  Linux
/dev/sda7       335581848   343983779     4200966   82  Linux swap / Solaris
/dev/sda8       343983843   385929494    20972826   83  Linux
/dev/sda9       385929558   427891274    20980858+  83  Linux
/dev/sda10      427891338   976768064   274438363+  83  Linux

Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00047cc1

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *          63   488392064   244196001   83  Linux

So, you can not fix a mounted partition. So, make sure to to un-mount with as root. Use the sequence:

init 1
umount /home
fsck /dev/sdb1

As for your partition setup, the EXT4 file system is the default and a more robust system in handling system errors. If you should get past this problem or if you decide to rebuild /dev/sdb1 again, go with EXT4 next time. As for your partition setup on /dev/sda, having 10 partitions is kind of extreme. It looks like you are booting from primary Extended Partition /dev/sda4 which the Windows boot manager will not understand. Be sure to stick with a Linux Partitioning program for this kind of setup. Good Luck.

Thank You,

When the filesystem is mounted at boot time, I got this problem. If I mount the filesystem after boot time, it mounts without any problem.
So I think the filesystem is not the problem but the way it is mounted during boot time.

On Tue, 23 Oct 2012 07:56:02 GMT, jvolkers
<jvolkers@no-mx.forums.opensuse.org> wrote:

>
>When the filesystem is mounted at boot time, I got this problem. If I
>mount the filesystem after boot time, it mounts without any problem.
>So I think the filesystem is not the problem but the way it is mounted
>during boot time.

OK.

please do

Code

cat /etc/fstab

/Code

and the same for the mount command you use.

code blocks take the advanced editor on the web interface.

?-)


/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part3 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part7 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part5 /                    ext3       acl,user_xattr        1 1
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part8 /opensuse11_4        ext3       defaults      1 1
/dev/disk/by-id/ata-ST3500630AS_9QG3CD8L-part10 /home2                ext4       defaults              1 2
/dev/disk/by-id/ata-SAMSUNG_HD250HJ_S0URJ1KQ501192-part1 /home ext3 noauto 1 2
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
netbook:/nfs/Backup    /netmount/backup    nfs    noauto,intr,soft 0 0
netbook:/nfs/jovo    /netmount/jovo        nfs    noauto,intr,soft 0 0
netbook:/nfs/Public    /netmount/public    nfs    noauto,intr,soft 0 0

My mount-command is simply


mount /home

How often do you reboot?

I am asking, because there is an apparent ext4 bug that is triggered by frequent mounting or rebooting.

EXT4 Data Corruption Bug Hits Stable Linux Kernels

Your symptoms sound a bit similar. I know you said ext3, but I think there’s a lot of common code between ext3 and ext4.

I also have a write up on the issue here in our forum: Stable Linux kernel hit by ext4 data corruption bug, but apparently it has affected but one person in the whole world.

Thank You,

On 2012-10-31 00:56, nrickert wrote:
> I am asking, because there is an apparent ext4 bug that is triggered by
> frequent mounting or rebooting.

You have to also use lazy umount, and I’m not sure if also some undocumented mount options.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

I boot my system mostly once each day

At this moment I do its this way:

  • the filesystem which give problems is NOT mounted at boot-time
  • I always startup in runlevel 3 (no graphical login)
  • as root I mount /home
    this raises no problems
  • after this I login as my normal user and issues startx

Shutdown is done as follows

  • I leave KDE
  • as root I issue a shutdown -h now
  • I do NOT umount /home explicitily
    That’s it.

To me it seems the problem is not caused by the shutdown-procedure but by the boot-procedure and the way the mounts are done.

I have some NFS-shares but they are also NOT automounted at boot-time

On 11/10/2012 03:06 AM, jvolkers wrote:
>
> nrickert;2500049 Wrote:
>> How often do you reboot?
>>
>> I am asking, because there is an apparent ext4 bug that is triggered by
>> frequent mounting or rebooting.
>>
>> ‘EXT4 Data Corruption Bug Hits Stable Linux Kernels’
>> (http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ)
>>
>> Your symptoms sound a bit similar. I know you said ext3, but I think
>> there’s a lot of common code between ext3 and ext4.
>
> I boot my system mostly once each day

To trigger that ext4 bug required a very special set of circumstances. First of
all, you needed to unmount the file system using the lazy (-l) option. That is
risky, and you had best know what you are doing. Secondly, you need to shut down
before the users of that file system have exited. The standard system does not
use that option, thus most users are not exposed to that bug.

The “too-soon” boot guess was just that when the developers were trying to
duplicate/analyze the problem. It was wrong.

After several kernel upgrades the problem still existed.
I have recreated the filesystem and changed it into ext4. I will report the results.

no file checking is done with a simple mount at boot fsck is run so you must first unmount home and then run fsck against it. I recommend you do this from a terminal (no GUI running) as root

Since my conversion from ext3 -> ext4 the problem did not appear anymore. As I shutdown and reboot my computer almost daily I think the original problem was in the ext3 implementation.