Skip to contentSkip to conversation

2.5.69-mm9

DISCUSSION Alistair J Strachan 3 participants 5 messages May 25, 2003

lore
Share & tools
lore
#0 lore raw
Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm9/

Quoted 10 lines

. 2.5.69-mm9 is not for the timid. It includes extensive changes to the
ext3 filesystem and the JBD layer. It withstood an hour of testing on my 4-way, but it probably has a couple of holes still.

The locking has been finegrained and sleeping locks have been removed - there are now no instances of lock_kernel(), lock_journal() or sleep_on()
in JBD or ext3. ext3 is much quicker on SMP machines.

Hi,

These changes don't even get to login for me. I changed the mm9 command line to include init=/bin/sh and got to a prompt. I was able to reproduce an enormous number of oopses by issuing:

mount -o remount,rw /

I tried to log it with klogd pointed to a different partition (vfat) but the problem segfaults klogd before it commits anything to disc. I'll probably try to do it via serial console this evening if nobody else can reproduce this.

Another oddity is that changing my / partition to ext2 in /etc/fstab and booting normally (i.e., without init=) doesn't make any difference. If these changes are ext3/jbd only, why is my ext3 volume mounted as ext2 still not mounting rw?

FWIW, all of my disc's partitions are ext3.

Cheers,
Alistair.

#1 lore raw
Quoted 11 lines · Alistair J Strachan

These changes don't even get to login for me. I changed the mm9 command line to include init=/bin/sh and got to a prompt. I was able to reproduce an enormous number of oopses by issuing:

mount -o remount,rw /

I tried to log it with klogd pointed to a different partition (vfat) but the problem segfaults klogd before it commits anything to disc. I'll probably try to do it via serial console this evening if nobody else can reproduce this.

It sounds like that would be a useful course of action.

Quoted 4 lines

Another oddity is that changing my / partition to ext2 in /etc/fstab and booting normally (i.e., without init=) doesn't make any difference. If these changes are ext3/jbd only, why is my ext3 volume mounted as ext2 still not mounting rw?

Changing fstab will not cause / to be mounted by ext2: the kernel makes the decision for /. You may be able to use "rootfstype=" (I don't think I've ever tried it).

The proper way to convert to ext2 is:

- boot with init=/bin/sh

- /sbin/tune2fs -O ^has_journal /dev/hda1

- /sbin/e2fsck -fy /dev/hda1

- reboot, edit /etc/fstab for the non-root filesystems.

#2 lore raw
Quoted 7 lines · you

Changing fstab will not cause / to be mounted by ext2: the kernel makes the decision for /. You may be able to use "rootfstype=" (I don't think I've ever tried it).

The proper way to convert to ext2 is:

Quoted 7 lines

- boot with init=/bin/sh

- /sbin/tune2fs -O ^has_journal /dev/hda1

- /sbin/e2fsck -fy /dev/hda1

- reboot, edit /etc/fstab for the non-root filesystems.

Thanks for this info. I just removed the journal and now have / mounted permanently as ext2. -mm9 got to login without a problem. I deliberately kept my /home volume as ext3 but commented it out in /etc/fstab.

I logged in as root and did:

mount -t ext3 /dev/discs/disc0/part3 /home

This also worked fine, I could read all the files on the volume. However, when I did:

touch /home/tmp
sync

The kernel barfed out the attached junk and the file was never committed. The volume was not corrupted as I was able to reboot with -mm6 and all is fine. tmp does not exist on the volume.

Presumably this is of more help to you. Since / is now ext2, I'm unencumbered and so will be able to test anything you like.

Cheers,
Alistair.

#3 lore raw
Quoted 2 lines · Alistair J Strachan

The kernel barfed out the attached junk

oops. It needs either CONFIG_SMP or CONFIG_DEBUG_SPINLOCK.

I don't know why you hit the final assertion failure in __journal_remove_journal_head(). Please see if adding CONFIG_DEBUG_SPINLOCK makes that go away.

#4 lore raw
In reply to Alistair J Strachan
Quoted 6 lines · Alistair J Strachan

touch /home/tmp
sync

The kernel barfed out the attached junk and the file was never committed. The volume was not corrupted as I was able to reboot with -mm6 and all is fine. tmp does not exist on the volume.

Be sure to run e2fsck -f on your /home partition because some changes could have been made to the filesystem that happen before a directory entry would be changed, suck as bitmaps or somesuch.