* 2.4.19pre8aa3 @ 2002-05-15 21:27 Andrea Arcangeli 2002-05-15 21:56 ` 2.4.19pre8aa3 Andreas Dilger ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-15 21:27 UTC (permalink / raw) To: linux-kernel 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 :) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-15 21:27 2.4.19pre8aa3 Andrea Arcangeli @ 2002-05-15 21:56 ` Andreas Dilger 2002-05-16 2:18 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-15 22:30 ` 2.4.19pre8aa3 Rik van Riel 2002-05-16 19:26 ` 2.4.19pre8aa3 Christoph Hellwig 2 siblings, 1 reply; 20+ messages in thread From: Andreas Dilger @ 2002-05-15 21:56 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: linux-kernel 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-15 21:56 ` 2.4.19pre8aa3 Andreas Dilger @ 2002-05-16 2:18 ` Andrea Arcangeli 0 siblings, 0 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 2:18 UTC (permalink / raw) To: linux-kernel; +Cc: Andreas Dilger 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-15 21:27 2.4.19pre8aa3 Andrea Arcangeli 2002-05-15 21:56 ` 2.4.19pre8aa3 Andreas Dilger @ 2002-05-15 22:30 ` Rik van Riel 2002-05-16 2:01 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 19:26 ` 2.4.19pre8aa3 Christoph Hellwig 2 siblings, 1 reply; 20+ messages in thread From: Rik van Riel @ 2002-05-15 22:30 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: linux-kernel 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-15 22:30 ` 2.4.19pre8aa3 Rik van Riel @ 2002-05-16 2:01 ` Andrea Arcangeli 2002-05-16 2:06 ` 2.4.19pre8aa3 Rik van Riel 2002-05-16 3:12 ` 2.4.19pre8aa3 Andrew Morton 0 siblings, 2 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 2:01 UTC (permalink / raw) To: Rik van Riel; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 2:01 ` 2.4.19pre8aa3 Andrea Arcangeli @ 2002-05-16 2:06 ` Rik van Riel 2002-05-16 2:32 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 3:12 ` 2.4.19pre8aa3 Andrew Morton 1 sibling, 1 reply; 20+ messages in thread From: Rik van Riel @ 2002-05-16 2:06 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: linux-kernel 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 2:06 ` 2.4.19pre8aa3 Rik van Riel @ 2002-05-16 2:32 ` Andrea Arcangeli 2002-05-16 2:42 ` 2.4.19pre8aa3 Rik van Riel ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 2:32 UTC (permalink / raw) To: Rik van Riel; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 2:32 ` 2.4.19pre8aa3 Andrea Arcangeli @ 2002-05-16 2:42 ` Rik van Riel 2002-05-16 2:58 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 8:36 ` 2.4.19pre8aa3 Russell King 2002-05-16 9:27 ` 2.4.19pre8aa3 Juan Quintela 2 siblings, 1 reply; 20+ messages in thread From: Rik van Riel @ 2002-05-16 2:42 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: linux-kernel 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 2:42 ` 2.4.19pre8aa3 Rik van Riel @ 2002-05-16 2:58 ` Andrea Arcangeli 0 siblings, 0 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 2:58 UTC (permalink / raw) To: Rik van Riel; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 2:32 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 2:42 ` 2.4.19pre8aa3 Rik van Riel @ 2002-05-16 8:36 ` Russell King 2002-05-16 8:59 ` 2.4.19pre8aa3 Russell King 2002-05-16 12:56 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 9:27 ` 2.4.19pre8aa3 Juan Quintela 2 siblings, 2 replies; 20+ messages in thread From: Russell King @ 2002-05-16 8:36 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: Rik van Riel, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 8:36 ` 2.4.19pre8aa3 Russell King @ 2002-05-16 8:59 ` Russell King 2002-05-16 12:56 ` 2.4.19pre8aa3 Andrea Arcangeli 1 sibling, 0 replies; 20+ messages in thread From: Russell King @ 2002-05-16 8:59 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: Rik van Riel, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 8:36 ` 2.4.19pre8aa3 Russell King 2002-05-16 8:59 ` 2.4.19pre8aa3 Russell King @ 2002-05-16 12:56 ` Andrea Arcangeli 1 sibling, 0 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 12:56 UTC (permalink / raw) To: Russell King; +Cc: Rik van Riel, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 2:32 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 2:42 ` 2.4.19pre8aa3 Rik van Riel 2002-05-16 8:36 ` 2.4.19pre8aa3 Russell King @ 2002-05-16 9:27 ` Juan Quintela 2002-05-16 16:07 ` 2.4.19pre8aa3 Andrea Arcangeli 2 siblings, 1 reply; 20+ messages in thread From: Juan Quintela @ 2002-05-16 9:27 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: Rik van Riel, linux-kernel >>>>> "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 9:27 ` 2.4.19pre8aa3 Juan Quintela @ 2002-05-16 16:07 ` Andrea Arcangeli 2002-05-16 18:37 ` 2.4.19pre8aa3 Rik van Riel 0 siblings, 1 reply; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 16:07 UTC (permalink / raw) To: Juan Quintela; +Cc: Rik van Riel, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 16:07 ` 2.4.19pre8aa3 Andrea Arcangeli @ 2002-05-16 18:37 ` Rik van Riel 2002-05-16 18:59 ` 2.4.19pre8aa3 Andrea Arcangeli 0 siblings, 1 reply; 20+ messages in thread From: Rik van Riel @ 2002-05-16 18:37 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: Juan Quintela, linux-kernel 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 18:37 ` 2.4.19pre8aa3 Rik van Riel @ 2002-05-16 18:59 ` Andrea Arcangeli 0 siblings, 0 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 18:59 UTC (permalink / raw) To: Rik van Riel; +Cc: Juan Quintela, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 2:01 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 2:06 ` 2.4.19pre8aa3 Rik van Riel @ 2002-05-16 3:12 ` Andrew Morton 2002-05-16 3:23 ` 2.4.19pre8aa3 Andrea Arcangeli 1 sibling, 1 reply; 20+ messages in thread From: Andrew Morton @ 2002-05-16 3:12 UTC (permalink / raw) To: Andrea Arcangeli; +Cc: Rik van Riel, linux-kernel 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; - ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 3:12 ` 2.4.19pre8aa3 Andrew Morton @ 2002-05-16 3:23 ` Andrea Arcangeli 0 siblings, 0 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-16 3:23 UTC (permalink / raw) To: Andrew Morton; +Cc: Rik van Riel, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-15 21:27 2.4.19pre8aa3 Andrea Arcangeli 2002-05-15 21:56 ` 2.4.19pre8aa3 Andreas Dilger 2002-05-15 22:30 ` 2.4.19pre8aa3 Rik van Riel @ 2002-05-16 19:26 ` Christoph Hellwig 2002-05-31 20:34 ` 2.4.19pre8aa3 Andrea Arcangeli 2 siblings, 1 reply; 20+ messages in thread From: Christoph Hellwig @ 2002-05-16 19:26 UTC (permalink / raw) To: Andrea Arcangeli, Marcelo Tosatti; +Cc: linux-kernel 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.. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.4.19pre8aa3 2002-05-16 19:26 ` 2.4.19pre8aa3 Christoph Hellwig @ 2002-05-31 20:34 ` Andrea Arcangeli 0 siblings, 0 replies; 20+ messages in thread From: Andrea Arcangeli @ 2002-05-31 20:34 UTC (permalink / raw) To: Christoph Hellwig, Marcelo Tosatti, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2002-05-31 20:35 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-05-15 21:27 2.4.19pre8aa3 Andrea Arcangeli 2002-05-15 21:56 ` 2.4.19pre8aa3 Andreas Dilger 2002-05-16 2:18 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-15 22:30 ` 2.4.19pre8aa3 Rik van Riel 2002-05-16 2:01 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 2:06 ` 2.4.19pre8aa3 Rik van Riel 2002-05-16 2:32 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 2:42 ` 2.4.19pre8aa3 Rik van Riel 2002-05-16 2:58 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 8:36 ` 2.4.19pre8aa3 Russell King 2002-05-16 8:59 ` 2.4.19pre8aa3 Russell King 2002-05-16 12:56 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 9:27 ` 2.4.19pre8aa3 Juan Quintela 2002-05-16 16:07 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 18:37 ` 2.4.19pre8aa3 Rik van Riel 2002-05-16 18:59 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 3:12 ` 2.4.19pre8aa3 Andrew Morton 2002-05-16 3:23 ` 2.4.19pre8aa3 Andrea Arcangeli 2002-05-16 19:26 ` 2.4.19pre8aa3 Christoph Hellwig 2002-05-31 20:34 ` 2.4.19pre8aa3 Andrea Arcangeli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).