2.4.19pre8aa3

2.4.19pre8aa3

[Andrea Arcangeli]

The main differences with the previous aa2 are:

o	sparc64 should work now (untested)
o	merged NUMA-Q NUMA arch support from IBM
o	various other fixes also from -ac
o	minor bdflush tuning difference to avoid char-writer in bonnie
	to stall and to slowdown too much (can make a difference in real
	life)
o	latest UML (also fixed initrd loading)
o	really release initrd ram0 memory

URL full -aa patchkit:

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre8aa3.gz
	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre8aa3/

Only the VM changes in the -aa patchkit against vanilla 2.4.19pre8
(ready for inclusion in mainline):

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.19pre8/vm-35.gz
	http://www.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.19pre8/vm-35/

Diff between 2.4.19pre8aa2 and 2.4.19pre8aa3:

Only in 2.4.19pre8aa3: 00_bdflush-tuning-1

	Put the mid watermark at 50% (near the high watermark so we don't stall
	too much).

Only in 2.4.19pre8aa3: 00_dnotify-cleanup-1

	Dnotify cleanups (minor improvements actually) from 2.4.19pre8ac2.

Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1

	Make sure to always try mounting with ext3 before ext2 (otherwise
	it's impossible to mount the real rootfs with ext3 if ext3 is a module
	loaded by an initrd and ext2 is linked into the kernel).

Only in 2.4.19pre8aa2: 00_initrd-free-1
Only in 2.4.19pre8aa3: 00_initrd-free-2

	Backout wrong patch and insert the printk fix. However the unmount in
	/old keeps returning -EINVAL of course, that's at the very least
	misleading, it would also be nice some documentation on the exact
	semantics of MS_MOVE, tested mount --move under UML but it's not at all
	clear what's going on with the "/", ".", ".." and didn't had the time
	to reverse engeneer the semantics from the code in do_move_mount yet
	(started and I will continue in the next days, but interpreting the code
	with some basic lines of what I should expect would be faster).  Printk
	fix from Al.

Only in 2.4.19pre8aa3: 00_reaper-thread-race-1

	SMP race fix that avoids losing reference of zombies with threads exits
	from 2.4.19pre8ac2.

Only in 2.4.19pre8aa3: 00_ufs-compile-1
Only in 2.4.19pre8aa3: 00_umem-compile-1

	Compile fixes (ufs from Hubert Mantel).

Only in 2.4.19pre8aa2: 05_vm_10_read_write_tweaks-1
Only in 2.4.19pre8aa3: 05_vm_10_read_write_tweaks-2

	Avoid backing out the flush_page_to_ram in this vm patch,
	the one on the pagecache is still needed before the memcpy
	on the pagecache during the early cow (would be cleaner
	to move it up, if Hugh wants to clean it up that's welcome,
	it will be an orthogonal patch, so far I just avoid to
	change that area in my changes, not high prio to clean it up
	as DaveM side it's more high prio to conver the users of
	flush_page_to_ram API to flush_dcache_page/icache new API during 2.5).

Only in 2.4.19pre8aa3: 21_pte-highmem-24-sparc64

	Now -aa is suposed to work fine with sparc64 (still untested though).

Only in 2.4.19pre8aa2: 50_uml-patch-2.4.18-22.gz
Only in 2.4.19pre8aa3: 50_uml-patch-2.4.18-25.gz
Only in 2.4.19pre8aa3: 52_uml-sys-read-write-1
Only in 2.4.19pre8aa2: 59_uml-compat-2.5-1
Only in 2.4.19pre8aa3: 59_uml-compat-2.5-2
Only in 2.4.19pre8aa2: 62_tux-uml-1
Only in 2.4.19pre8aa3: 62_tux-uml-2

	UML updates (in particular fixes initrd loading, in previous version
	read/write/lseek was calling glibc read/write/lseek on the host instead
	of sys_read/sys_write/sys_lseek :).

Only in 2.4.19pre8aa2: 91_zone_start_pfn-2
Only in 2.4.19pre8aa3: 91_zone_start_pfn-3

	Convert all archs to the new API (including sparc64, guess why :).

Only in 2.4.19pre8aa3: 93_NUMAQ-1

	NUMA-Q support from Patricia Gaughen (very clean integration, I liked
	it).

Andrea

PS. Leaving in a few minutes to go watch the attack of the clones :)

Re: 2.4.19pre8aa3

[Andreas Dilger]

On May 15, 2002  23:27 +0200, Andrea Arcangeli wrote:
> Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1
> 
> 	Make sure to always try mounting with ext3 before ext2 (otherwise
> 	it's impossible to mount the real rootfs with ext3 if ext3 is a module
> 	loaded by an initrd and ext2 is linked into the kernel).

Hmm, I don't think this is true.  While I'm not an initrd user, people
have been doing this with RH for quite some time.  Note that it is not
necessarily true that they get it _correct_ all the time, but eventually
it works.  Apparently you need to explicitly specify the root filesystem
type for the initrd mount.

Note that I haven't seen the patch in question yet (mirrors don't have
it), but somehow I don't think that changing the order of the
registration is going to help.  If they have both ext2 and ext3 as
modules, and insmod ext3 first and ext2 second, you've just broken
their setup.  Similarly, (depending on how it is done) I imagine this
would break kernels that have both ext3 and ext2 compiled in.

The only reasonable solution is to not guess at the root filesystem type
and mount it with the correct type explicitly.  I think the RH mkinitrd
will check /etc/filesystems for the root fs and use the type there.  If
the user forgets to run mkinitrd after changing their kernel, there is
not much you can do about that.

What _may_ be helpful is if ext2 printed a small warning that it is
mounting a filesystem with a journal as ext2 and no journaling will
be done, if the user really wanted to do that (normally they will not).

This will at least alert some users that their root filesystem is not
being mounted as ext3 and eliminate a number of support requests on
ext2-devel when initrd users are wondering why e2fsck is being run on
their supposedly journaled filesystem.  The fact that "mount" output
shows ext3 as the filesystem type (while 'cat /proc/mounts' shows ext2)
does nothing to help the user figure out what is wrong.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: 2.4.19pre8aa3

[Rik van Riel]

On Wed, 15 May 2002, Andrea Arcangeli wrote:

> Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1
>
> 	Make sure to always try mounting with ext3 before ext2 (otherwise
> 	it's impossible to mount the real rootfs with ext3 if ext3 is a module
> 	loaded by an initrd and ext2 is linked into the kernel).

Funny, I've been doing this for months.

Maybe you should look into pivot_mount(2) and pivot_mount(8)
some day ?

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Wed, May 15, 2002 at 07:30:18PM -0300, Rik van Riel wrote:
> On Wed, 15 May 2002, Andrea Arcangeli wrote:
> 
> > Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1
> >
> > 	Make sure to always try mounting with ext3 before ext2 (otherwise
> > 	it's impossible to mount the real rootfs with ext3 if ext3 is a module
> > 	loaded by an initrd and ext2 is linked into the kernel).
> 
> Funny, I've been doing this for months.
> 
> Maybe you should look into pivot_mount(2) and pivot_mount(8)
> some day ?

I'm not sure if you really understood what the problem is from my
description above because your kind suggestion doesn't make sense to me.

First of all there's no pivot_mount but there's only pivot_root (never
mind, it is clear you meant pivot_root).

Secondly pivot_root has nothing to do with handle_initrd.

Go read init/do_mounts.c::handle_initrd. There are only two ways:

1) you specified rootfstype=ext3, then the real rootfs will be
   mounted as ext3 and not as ext2, but the initrd must also
   be mountable by ext3 and that's not the case normally (the same
   rootfstype will apply to both the initrd and the real root fs,
   the fact rootfstype applies to both doesn't make sense but
   that's another issue and I don't want to be forced to use
   rootfstype anyways, I don't like having to pass an argument for
   something that can be done at runtime by the kernel).
2) you didn't specified rootfstype=, in such case ext2 will be
   tried first because it got registered first because ext2 is linked
   into the kernel and ext3 is a module

That's all, and that's an autodetection bug because ext3 must be always
tried first, there's no point at all to try to mount with ext2 before
ext3 (of course unless rootfstype= is specified).

If it works for you it means you regularly reboot with SYSRQ+B (or
some workaround on those lines), and so ext2 doesn't mount
and in turn ext3 is later tried. otherwise if ext2 mounts cleanly ext3
is _never_ tried and you cannot mount ext3 as rootfs without my patch
that enforces the ordering.

Make sure to check with /proc/mounts that your rootfs is really using
ext3 and not ext2, or you may not notice.

If it works for you it's probably because ext2 is a module too, or maybe
more simply because ext3 is linked into the kernel.

Andrea

Re: 2.4.19pre8aa3

[Rik van Riel]

On Thu, 16 May 2002, Andrea Arcangeli wrote:
> On Wed, May 15, 2002 at 07:30:18PM -0300, Rik van Riel wrote:
> > On Wed, 15 May 2002, Andrea Arcangeli wrote:
> >
> > > Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1
> > >
> > > 	Make sure to always try mounting with ext3 before ext2 (otherwise
> > > 	it's impossible to mount the real rootfs with ext3 if ext3 is a module
> > > 	loaded by an initrd and ext2 is linked into the kernel).
> >
> > Funny, I've been doing this for months.
> >
> > Maybe you should look into pivot_mount(2) and pivot_mount(8)
> > some day ?

> First of all there's no pivot_mount but there's only pivot_root (never
> mind, it is clear you meant pivot_root).
>
> Secondly pivot_root has nothing to do with handle_initrd.
>
> Go read init/do_mounts.c::handle_initrd. There are only two ways:

There's a third way, which is used on the initrd of most
distros:

--- snip from linuxrc ----
mount --ro -t $rootfs $rootdev /sysroot
pivot_root /sysroot /sysroot/initrd
------

This way you can specify both the root fs and - if wanted -
special mount options to the root fs. Then you pivot_root(2)
to move the root fs to / and the (old) initrd to /initrd.

The initscripts then umount /initrd, after which the initrd
data gets freed.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Wed, May 15, 2002 at 03:56:21PM -0600, Andreas Dilger wrote:
> On May 15, 2002  23:27 +0200, Andrea Arcangeli wrote:
> > Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1
> > 
> > 	Make sure to always try mounting with ext3 before ext2 (otherwise
> > 	it's impossible to mount the real rootfs with ext3 if ext3 is a module
> > 	loaded by an initrd and ext2 is linked into the kernel).
> 
> Hmm, I don't think this is true.  While I'm not an initrd user, people
> have been doing this with RH for quite some time.  Note that it is not
> necessarily true that they get it _correct_ all the time, but eventually
> it works.  Apparently you need to explicitly specify the root filesystem
> type for the initrd mount.
> 
> Note that I haven't seen the patch in question yet (mirrors don't have
> it), but somehow I don't think that changing the order of the
> registration is going to help.  If they have both ext2 and ext3 as

it helps, it cures the autodetection bug for me.

> modules, and insmod ext3 first and ext2 second, you've just broken
> their setup.  Similarly, (depending on how it is done) I imagine this
> would break kernels that have both ext3 and ext2 compiled in.

can you elaborate what actually breaks in trying ext3 before ext2? That
is the right thing to do always, if the fs is ext3 it must be mounted
ext3 not ext2. If ext3 fails because the journal is missing, then ext2
will be used as expected, that's the right ordering.

> The only reasonable solution is to not guess at the root filesystem type
> and mount it with the correct type explicitly.  I think the RH mkinitrd

First I hate to do something that can be very well done at runtime by
the kernel accurately at ~zero cost. But anyways you can't workaround
the problem with rootfstype, if you do you will be forced to use ext3
for the filesystem on the initrd too (for all the wrong reasons, but
that's another problem and one that I'm not interested to fix because I
pretend the autodetection to work always) and that's never the case
normally, it doesn't even make any sense to use journaling on a ramdisk.
initrd will be a minixfs or an ext2, never an ext3.

> will check /etc/filesystems for the root fs and use the type there.  If
> the user forgets to run mkinitrd after changing their kernel, there is
> not much you can do about that.
> 
> What _may_ be helpful is if ext2 printed a small warning that it is

the issue is not to know about the fact the root fs is been mounted by
ext2 despite it's an ext3, the issue is that after your learnt the bad
news, you still cannot mount it as ext3 unless you use workarounds that
somehow make the mount to fail as ext2 first, like a SYSRQ+B. The patch
fixes this completly and permanently, no matter of the ext2/ext3
module/linked 4 possible combinations.

> mounting a filesystem with a journal as ext2 and no journaling will
> be done, if the user really wanted to do that (normally they will not).
> 
> This will at least alert some users that their root filesystem is not
> being mounted as ext3 and eliminate a number of support requests on
> ext2-devel when initrd users are wondering why e2fsck is being run on
> their supposedly journaled filesystem.  The fact that "mount" output
> shows ext3 as the filesystem type (while 'cat /proc/mounts' shows ext2)
> does nothing to help the user figure out what is wrong.

This is true, mount is very misleading in that case so the warning is a
good idea, but this is orthogonal to my fix. And after my fix the
warning will correctly happen only if the user doesn't have ext3 into
his kernel. Now instead the warning would happen even with ext3 loaded
as module into the kernel, and that's the bug.

Andrea

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Wed, May 15, 2002 at 11:06:51PM -0300, Rik van Riel wrote:
> On Thu, 16 May 2002, Andrea Arcangeli wrote:
> > On Wed, May 15, 2002 at 07:30:18PM -0300, Rik van Riel wrote:
> > > On Wed, 15 May 2002, Andrea Arcangeli wrote:
> > >
> > > > Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1
> > > >
> > > > 	Make sure to always try mounting with ext3 before ext2 (otherwise
> > > > 	it's impossible to mount the real rootfs with ext3 if ext3 is a module
> > > > 	loaded by an initrd and ext2 is linked into the kernel).
> > >
> > > Funny, I've been doing this for months.
> > >
> > > Maybe you should look into pivot_mount(2) and pivot_mount(8)
> > > some day ?
> 
> > First of all there's no pivot_mount but there's only pivot_root (never
> > mind, it is clear you meant pivot_root).
> >
> > Secondly pivot_root has nothing to do with handle_initrd.
> >
> > Go read init/do_mounts.c::handle_initrd. There are only two ways:
> 
> There's a third way, which is used on the initrd of most
> distros:

I'm not using the full blown initrd of most distros that is aware of the
mistery of life and of all the kernel bugs out there too, my own dumb
linuxrc just says:

	echo hello world

and then returns, and ext3 gets mounted as ext2 and that's a kernel bug,
all other fs gets mounted correctly with my initrd, only ext3 gone wrong
until I fixed it.

> --- snip from linuxrc ----
> mount --ro -t $rootfs $rootdev /sysroot
> pivot_root /sysroot /sysroot/initrd
> ------
> 
> This way you can specify both the root fs and - if wanted -
> special mount options to the root fs. Then you pivot_root(2)
> to move the root fs to / and the (old) initrd to /initrd.

both lines are completly superflous, very misleading as well. I
recommend to drop such two lines from all the full blown bug-aware
linuxrc out there (of course after you apply the ordering fix to the
kernel).

About the "special mount options", now since 2.4.19pre if you try to
pass different flags to your mount in linuxrc and the kernel, you will
fail to mount the real root fs, if you want to pass the "if wanted
special mount options" they must be passed via the kernel parameter
only, they cannot be inside the linuxrc knowledge or the kernel mount
will fail.

> 
> The initscripts then umount /initrd, after which the initrd
> data gets freed.

you also need to call flushb /dev/ram0 to free the initrd memory after
umount /initrd, if you do it in userspace without using the automation
in do_mounts.c.

Andrea

Re: 2.4.19pre8aa3

[Rik van Riel]

On Thu, 16 May 2002, Andrea Arcangeli wrote:

> I'm not using the full blown initrd of most distros that is aware of the

Then I guess we found the problem. ;)

> > --- snip from linuxrc ----
> > mount --ro -t $rootfs $rootdev /sysroot
> > pivot_root /sysroot /sysroot/initrd
> > ------

> both lines are completly superflous, very misleading as well. I
> recommend to drop such two lines from all the full blown bug-aware
> linuxrc out there (of course after you apply the ordering fix to the
> kernel).

Personally I hope the special initrd code gets moved from
kernelspace into userspace.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Wed, May 15, 2002 at 11:42:24PM -0300, Rik van Riel wrote:
> On Thu, 16 May 2002, Andrea Arcangeli wrote:
> 
> > I'm not using the full blown initrd of most distros that is aware of the
> 
> Then I guess we found the problem. ;)

disagreement, my initrd is not the problem. the kernel code is really
explicit about what it will do with the real root fs, it will mount it
by itself, I am definitely not required to mount it by myself within
linuxrc, for sure not to workaround a bug in the kernel, and now in
2.4.19pre mounting it in linuxrc is even worse idea because the mount
will likely fail at the first different mount option. linuxrc is allowed
to just run exit(2) and the real root fs must still be mouned correctly,
that is the linuxrc API.

> 
> > > --- snip from linuxrc ----
> > > mount --ro -t $rootfs $rootdev /sysroot
> > > pivot_root /sysroot /sysroot/initrd
> > > ------
> 
> > both lines are completly superflous, very misleading as well. I
> > recommend to drop such two lines from all the full blown bug-aware
> > linuxrc out there (of course after you apply the ordering fix to the
> > kernel).
> 
> Personally I hope the special initrd code gets moved from
> kernelspace into userspace.

I don't care about this part, if it gets changed I will update my
initscripts to act accordingly, however requiring all linux users to
update their init scripts in mid/late 2.4 is probably not a good idea,
if you really want to drop such two lines then do it in 2.5 only (not
recommended, still it's a gratuitous API change IMHO).

Andrea

Re: 2.4.19pre8aa3

[Andrew Morton]

Andrea Arcangeli wrote:
> 
> ...
> That's all, and that's an autodetection bug because ext3 must be always
> tried first, there's no point at all to try to mount with ext2 before
> ext3 (of course unless rootfstype= is specified).

It is *very* common problem for people to think that their root fs is ext3
when in fact it is being mounted as ext2.

It seems that /etc/mtab incorrectly reports ext3, which doesn't help.
The real truth is revealed in /proc/mounts.  (Which has this irritating
"/dev/root" thing in it, btw).

So anything we can do to simplify this problem for people would be
really good.  (It would be good if kernel.org came back, too, so we
can see the patch ;))

And Andreas' idea of "Warning: mounting ext3 as as ext2" will help,
too.

--- 2.4.19-pre8/fs/ext2/super.c~ext2-ext3-warning	Wed May 15 19:36:12 2002
+++ 2.4.19-pre8-akpm/fs/ext2/super.c	Wed May 15 20:11:41 2002
@@ -486,6 +486,9 @@ struct super_block * ext2_read_super (st
 		       bdevname(dev), i);
 		goto failed_mount;
 	}
+	if (EXT2_HAS_COMPAT_FEATURE(sb, EXT3_FEATURE_COMPAT_HAS_JOURNAL))
+		ext2_warning(sb, __FUNCTION__,
+			"mounting ext3 filesystem as ext2\n");
 	sb->s_blocksize_bits =
 		le32_to_cpu(EXT2_SB(sb)->s_es->s_log_block_size) + 10;
 	sb->s_blocksize = 1 << sb->s_blocksize_bits;


-

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Wed, May 15, 2002 at 08:12:04PM -0700, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> > 
> > ...
> > That's all, and that's an autodetection bug because ext3 must be always
> > tried first, there's no point at all to try to mount with ext2 before
> > ext3 (of course unless rootfstype= is specified).
> 
> It is *very* common problem for people to think that their root fs is ext3
> when in fact it is being mounted as ext2.
> 
> It seems that /etc/mtab incorrectly reports ext3, which doesn't help.
> The real truth is revealed in /proc/mounts.  (Which has this irritating
> "/dev/root" thing in it, btw).
> 
> So anything we can do to simplify this problem for people would be
> really good.  (It would be good if kernel.org came back, too, so we
> can see the patch ;))

Here it is, it's short enough that I can post it here too. it falls into
the obviously right category IMHO.

--- 2.4.19pre8aa3/fs/ext3/super.c.~1~	Mon Feb 25 22:05:08 2002
+++ 2.4.19pre8aa3/fs/ext3/super.c	Fri May 10 14:09:28 2002
@@ -1736,7 +1736,7 @@
 
 static int __init init_ext3_fs(void)
 {
-        return register_filesystem(&ext3_fs_type);
+        return register_filesystem_lifo(&ext3_fs_type);
 }
 
 static void __exit exit_ext3_fs(void)
--- 2.4.19pre8aa3/fs/super.c.~1~	Thu May  9 23:30:07 2002
+++ 2.4.19pre8aa3/fs/super.c	Fri May 10 14:08:29 2002
@@ -89,7 +89,7 @@
  *	unregistered.
  */
  
-int register_filesystem(struct file_system_type * fs)
+int __register_filesystem(struct file_system_type * fs, int lifo)
 {
 	int res = 0;
 	struct file_system_type ** p;
@@ -103,8 +103,14 @@
 	p = find_filesystem(fs->name);
 	if (*p)
 		res = -EBUSY;
-	else
-		*p = fs;
+	else {
+		if (!lifo)
+			*p = fs;
+		else {
+			fs->next = file_systems;
+			file_systems = fs;
+		}
+	}
 	write_unlock(&file_systems_lock);
 	return res;
 }
--- 2.4.19pre8aa3/include/linux/fs.h.~1~	Fri May 10 00:46:11 2002
+++ 2.4.19pre8aa3/include/linux/fs.h	Fri May 10 14:16:54 2002
@@ -1077,7 +1077,9 @@
 		__MOD_DEC_USE_COUNT((fops)->owner);	\
 } while(0)
 
-extern int register_filesystem(struct file_system_type *);
+extern int __register_filesystem(struct file_system_type *, int);
+#define register_filesystem(fs) __register_filesystem(fs, 0)
+#define register_filesystem_lifo(fs) __register_filesystem(fs, 1)
 extern int unregister_filesystem(struct file_system_type *);
 extern struct vfsmount *kern_mount(struct file_system_type *);
 extern int may_umount(struct vfsmount *);
--- 2.4.19pre8aa3/kernel/ksyms.c.~1~	Thu May  9 23:30:06 2002
+++ 2.4.19pre8aa3/kernel/ksyms.c	Fri May 10 14:14:22 2002
@@ -355,7 +355,7 @@
 EXPORT_SYMBOL(do_SAK);
 
 /* filesystem registration */
-EXPORT_SYMBOL(register_filesystem);
+EXPORT_SYMBOL(__register_filesystem);
 EXPORT_SYMBOL(unregister_filesystem);
 EXPORT_SYMBOL(kern_mount);
 EXPORT_SYMBOL(__mntput);

> And Andreas' idea of "Warning: mounting ext3 as as ext2" will help,
> too.
> 
> --- 2.4.19-pre8/fs/ext2/super.c~ext2-ext3-warning	Wed May 15 19:36:12 2002
> +++ 2.4.19-pre8-akpm/fs/ext2/super.c	Wed May 15 20:11:41 2002
> @@ -486,6 +486,9 @@ struct super_block * ext2_read_super (st
>  		       bdevname(dev), i);
>  		goto failed_mount;
>  	}
> +	if (EXT2_HAS_COMPAT_FEATURE(sb, EXT3_FEATURE_COMPAT_HAS_JOURNAL))
> +		ext2_warning(sb, __FUNCTION__,
> +			"mounting ext3 filesystem as ext2\n");
>  	sb->s_blocksize_bits =
>  		le32_to_cpu(EXT2_SB(sb)->s_es->s_log_block_size) + 10;
>  	sb->s_blocksize = 1 << sb->s_blocksize_bits;

agreed on this patch too.

Andrea

Re: 2.4.19pre8aa3

[Russell King]

On Thu, May 16, 2002 at 04:32:38AM +0200, Andrea Arcangeli wrote:
> On Wed, May 15, 2002 at 11:06:51PM -0300, Rik van Riel wrote:
> > --- snip from linuxrc ----
> > mount --ro -t $rootfs $rootdev /sysroot
> > pivot_root /sysroot /sysroot/initrd
> > ------
> > 
> > This way you can specify both the root fs and - if wanted -
> > special mount options to the root fs. Then you pivot_root(2)
> > to move the root fs to / and the (old) initrd to /initrd.
> 
> both lines are completly superflous, very misleading as well. I
> recommend to drop such two lines from all the full blown bug-aware
> linuxrc out there (of course after you apply the ordering fix to the
> kernel).

Have you thought about reading Documentation/initrd.txt and following
the described method?  (last modified December 2000 according to the
comments and the mtime on the file).

The method you're using has therefore been marked "obsolete" for almost
two and a half years:

| Obsolete root change mechanism
| ------------------------------
| 
| The following mechanism was used before the introduction of pivot_root.
| Current kernels still support it, but you should _not_ rely on its
| continued availability.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.4.19pre8aa3

[Russell King]

On Thu, May 16, 2002 at 09:36:30AM +0100, Russell King wrote:
> Have you thought about reading Documentation/initrd.txt and following
> the described method?  (last modified December 2000 according to the
> comments and the mtime on the file).
> 
> The method you're using has therefore been marked "obsolete" for almost
> two and a half years:

Of course that's one and a half.  initrd.txt changed in 2.4.0-test12
to be exact.

However, we shouldn't break the old initrd method in 2.4 - that's
what 2.5 is for, but ext3 is a new feature introduced after in 2.4.9.

So, the question becomes - is it reasonable to expect new features
introduced in a stable kernel series to work with obsolete methods
that have already been replaced with far better solutions.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.4.19pre8aa3

[Juan Quintela]

>>>>> "andrea" == Andrea Arcangeli <andrea@suse.de> writes:

Hi

andrea> I'm not using the full blown initrd of most distros that is aware of the
andrea> mistery of life and of all the kernel bugs out there too, my own dumb
andrea> linuxrc just says:

andrea> echo hello world

andrea> and then returns, and ext3 gets mounted as ext2 and that's a kernel bug,
andrea> all other fs gets mounted correctly with my initrd, only ext3 gone wrong
andrea> until I fixed it.

>> --- snip from linuxrc ----
>> mount --ro -t $rootfs $rootdev /sysroot
>> pivot_root /sysroot /sysroot/initrd
>> ------
>> 
>> This way you can specify both the root fs and - if wanted -
>> special mount options to the root fs. Then you pivot_root(2)
>> to move the root fs to / and the (old) initrd to /initrd.

andrea> both lines are completly superflous, very misleading as well. I
andrea> recommend to drop such two lines from all the full blown bug-aware
andrea> linuxrc out there (of course after you apply the ordering fix to the
andrea> kernel).

I am missing something, or how do you pass the notail option to your
reiserfs rootfs when the initrd is ext2.


Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Thu, May 16, 2002 at 09:36:30AM +0100, Russell King wrote:
> On Thu, May 16, 2002 at 04:32:38AM +0200, Andrea Arcangeli wrote:
> > On Wed, May 15, 2002 at 11:06:51PM -0300, Rik van Riel wrote:
> > > --- snip from linuxrc ----
> > > mount --ro -t $rootfs $rootdev /sysroot
> > > pivot_root /sysroot /sysroot/initrd
> > > ------
> > > 
> > > This way you can specify both the root fs and - if wanted -
> > > special mount options to the root fs. Then you pivot_root(2)
> > > to move the root fs to / and the (old) initrd to /initrd.
> > 
> > both lines are completly superflous, very misleading as well. I
> > recommend to drop such two lines from all the full blown bug-aware
> > linuxrc out there (of course after you apply the ordering fix to the
> > kernel).
> 
> Have you thought about reading Documentation/initrd.txt and following
> the described method?  (last modified December 2000 according to the
> comments and the mtime on the file).

I didn't noticed the API changed in the docs, so my suggestion of
yesterday to remove such two lines is wrong sorry. I was only reading
the kernel code and I was using my own old debugging initrd were I could
reproduce the ext3 problem. Interestingly there's no way to guess the
new API by only reading the kernel code like I was doing.

Andrea

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Thu, May 16, 2002 at 11:27:37AM +0200, Juan Quintela wrote:
> I am missing something, or how do you pass the notail option to your
> reiserfs rootfs when the initrd is ext2.

fair enough (the new initrd API allows that, but it's very ugly that it
is not dynamic from a kernel param like rootfstype would be, but it
instead has to be written on disk within the initrd), however as said
that's all due the brokeness of the rootfs params, they should apply
only to the fianl real root dev, never to the initrd.

Andrea

Re: 2.4.19pre8aa3

[Rik van Riel]

On Thu, 16 May 2002, Andrea Arcangeli wrote:
> On Thu, May 16, 2002 at 11:27:37AM +0200, Juan Quintela wrote:
> > I am missing something, or how do you pass the notail option to your
> > reiserfs rootfs when the initrd is ext2.
>
> fair enough (the new initrd API allows that, but it's very ugly that it
> is not dynamic from a kernel param like rootfstype would be, but it
> instead has to be written on disk within the initrd), however as said
> that's all due the brokeness of the rootfs params, they should apply
> only to the fianl real root dev, never to the initrd.

There's another issue.  The real root device might not be known
at the time the initrd is first loaded.

This is the case in some installers, which seem to use pivot_root
after the installer is done so the user doesn't need to reboot
after the install is done...

Of course, the real root device won't be known until after the user
has done the partitioning of the hard disk(s).

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Thu, May 16, 2002 at 03:37:49PM -0300, Rik van Riel wrote:
> On Thu, 16 May 2002, Andrea Arcangeli wrote:
> > On Thu, May 16, 2002 at 11:27:37AM +0200, Juan Quintela wrote:
> > > I am missing something, or how do you pass the notail option to your
> > > reiserfs rootfs when the initrd is ext2.
> >
> > fair enough (the new initrd API allows that, but it's very ugly that it
> > is not dynamic from a kernel param like rootfstype would be, but it
> > instead has to be written on disk within the initrd), however as said
> > that's all due the brokeness of the rootfs params, they should apply
> > only to the fianl real root dev, never to the initrd.
> 
> There's another issue.  The real root device might not be known
> at the time the initrd is first loaded.
> 
> This is the case in some installers, which seem to use pivot_root
> after the installer is done so the user doesn't need to reboot
> after the install is done...
> 
> Of course, the real root device won't be known until after the user
> has done the partitioning of the hard disk(s).

Sure I see that, and that's also allowed by the new initrd API, and in
such case you cannot make use of the two rootfs* params anyways because
as you say you don't know what the wanted partitioning in advance.

What i'm saying is that if you want to add notail option to the root
mount after you finished installing your system (so with a normally non
interactive initrd) you can't make use of the rootfs* parameters to
tweak the root mount during lilo (like you could do without initrd)
because they're applied to both initrd and real root dev and that's
clearly another bug (but not very important). And with the new initrd
API such bug basically doesn't matter because the rootfstype will be
forced in the static initrd image (while without initrd, or with the old
initrd API + the bugfix that applies rootfs* only to the root dev I
could make use of the rootfs* flags).

Andrea

Re: 2.4.19pre8aa3

[Christoph Hellwig]

On Wed, May 15, 2002 at 11:27:33PM +0200, Andrea Arcangeli wrote:
> o	minor bdflush tuning difference to avoid char-writer in bonnie
> 	to stall and to slowdown too much (can make a difference in real
> 	life)

...

> Only in 2.4.19pre8aa3: 00_bdflush-tuning-1
> 
> 	Put the mid watermark at 50% (near the high watermark so we don't stall
> 	too much).

As the 2.4.19-pre mainline got your buffer throtteling changes I guess it
has the same issues?  Do you think it's worth to submit that patch to Marcelo
even that late in the release cycle?

> Only in 2.4.19pre8aa2: 05_vm_10_read_write_tweaks-1
> Only in 2.4.19pre8aa3: 05_vm_10_read_write_tweaks-2
> 
> 	Avoid backing out the flush_page_to_ram in this vm patch,
> 	the one on the pagecache is still needed before the memcpy
> 	on the pagecache during the early cow (would be cleaner
> 	to move it up, if Hugh wants to clean it up that's welcome,
> 	it will be an orthogonal patch, so far I just avoid to
> 	change that area in my changes, not high prio to clean it up
> 	as DaveM side it's more high prio to conver the users of
> 	flush_page_to_ram API to flush_dcache_page/icache new API during 2.5).

It seems to me you ignore the comments akpm put in the split patches you
merged :)  Not only the comment to this change is superflous now, but also
I'd really like to get an answer to the remaining part of it as Andrew's
comment about that part beeing buggy makes a lot of sense to me..

Re: 2.4.19pre8aa3

[Andrea Arcangeli]

On Thu, May 16, 2002 at 08:26:26PM +0100, Christoph Hellwig wrote:
> On Wed, May 15, 2002 at 11:27:33PM +0200, Andrea Arcangeli wrote:
> > o	minor bdflush tuning difference to avoid char-writer in bonnie
> > 	to stall and to slowdown too much (can make a difference in real
> > 	life)
> 
> ...
> 
> > Only in 2.4.19pre8aa3: 00_bdflush-tuning-1
> > 
> > 	Put the mid watermark at 50% (near the high watermark so we don't stall
> > 	too much).
> 
> As the 2.4.19-pre mainline got your buffer throtteling changes I guess it
> has the same issues?  Do you think it's worth to submit that patch to Marcelo
> even that late in the release cycle?

it is not very important, but of course it could go in too.

> 
> > Only in 2.4.19pre8aa2: 05_vm_10_read_write_tweaks-1
> > Only in 2.4.19pre8aa3: 05_vm_10_read_write_tweaks-2
> > 
> > 	Avoid backing out the flush_page_to_ram in this vm patch,
> > 	the one on the pagecache is still needed before the memcpy
> > 	on the pagecache during the early cow (would be cleaner
> > 	to move it up, if Hugh wants to clean it up that's welcome,
> > 	it will be an orthogonal patch, so far I just avoid to
> > 	change that area in my changes, not high prio to clean it up
> > 	as DaveM side it's more high prio to conver the users of
> > 	flush_page_to_ram API to flush_dcache_page/icache new API during 2.5).
> 
> It seems to me you ignore the comments akpm put in the split patches you
> merged :)  Not only the comment to this change is superflous now, but also

updated :)

> I'd really like to get an answer to the remaining part of it as Andrew's
> comment about that part beeing buggy makes a lot of sense to me..

well, as Andrew said it's a microoptimization, but it's not buggy. It is
used to avoid marking a page referenced twice if somebody reads with an
userspace buffer granularity smaller than PAGE_SIZE, the same
optimization exists in the read side (there it is a bit more of a
microoptimization because the writer never activates pages but the
readers activates pages without such check).

Andrea