Re: Re: patch fr1-2.17 does not work with kernel 2.4.30

"Also sprach Stephan von Krawczynski:"
> > If it isn't already active, then it starts it, but if it is active,
> > then there is nothing that needs doing. If you want to see where it is
> > started you will have to look earlier in your trace. But there is no
> > urgent need to worry.
> 
> well, in fact I am pretty worried. And the reason is simple:
> There is _no_ way around a printk. If it is not in the logs, then there was no
> call. point.

I showed you the trace I got. I simply put a

    printk(KERN_DEBUG, "raid1: %s\n", __FUNCTION__);

at the head of each function body.

> But what I really do not understand is this:
> Why does the same hardware (and software) show this in non-persistent case:

> Whereas the persistent case looks like:
> 
> kernel: md: syncing RAID array md0
> kernel: md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc.
> kernel: md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction.
> kernel: md: using 124k window, over a total of 25679808 blocks.
> kernel: md0: removed bitmap f6630900

Probably the event count is not right. It's not worth thinking about
without a trace. This is from raid1_sync_request, on sector 0 of the
resync, and it tells us that the MD_SB_BITMAP_REPAIR(mddev->sb) flag
has not been set on the array superblock.

                /* also remove bitmap if not indicated */
                if (! MD_SB_BITMAP_REPAIR(mddev->sb)) {
                        /* has to be outside spinlock as it takes it */
                        printk(KERN_WARNING "md%d: removed bitmap %x\n",
                                mdidx(mddev), (unsigned)bitmap);
                        bitmap->stop (bitmap);

So the repair bit is not set in md.c. It is set in the hot_add_disk()
routine in md.c, when it is determined that a hotrepair should be done,
by virtue of the event count, disk uuid, and so on, visible in the nely
added disk:

        printk(KERN_DEBUG "md%d: set repair bit to %d on superblock\n",
                mdidx(mddev), hotrepair);
        MD_SB_BITMAP_REPAIR(mddev->sb) = hotrepair;
        mddev->sb_dirty = 1;
        md_update_sb(mddev);

        /*
         * Kick recovery, maybe this spare has to be added to the
         * array immediately.
         */
        md_recover_arrays();

        return 0;

and that MUST be visible in your trace. The printk's immediately before the
return 0|

> This is completely reproducable and I really can mkraid the thing 10 times flipflopping the persistence. Persistent-case always removes the bitmap, non-persistent always retains it.

There's no point in repeating. One time is enough. The hotrepair bit is
not set in md.c. It is set as follows:

        rdev = find_rdev(mddev, dev);
        if (rdev) {

                if (rdev->dev != dev || !rdev->faulty) {
                        printk(KERN_WARNING "md%d: cannot add existing component %x\n",
                                mdidx(mddev), dev);
                        return -EBUSY;
                }
                printk(KERN_WARNING "md%d: repair of faulty disk %x!\n",
                        mdidx(mddev), dev);

                err = hot_remove_disk(mddev, dev);
                if (err < 0) {
                        printk(KERN_WARNING "md%d: remove disk %x errored\n",
                                mdidx(mddev), dev);
                        return err;
                }
                hotrepair = 1;
                ^^^^^^^^^^^^^^^^ HERE
                rdev = NULL;
        }
        err = md_import_device (dev, persistent);
        if (err) {
                printk(KERN_WARNING "md: error, md_import_device() returned %d\n
", err);
                return -EINVAL;
        }
        rdev = find_rdev_all(dev);
 
and all other exits have printks in. SO you must see a trace. This if
block determines if hotrepair is feasible.



> Where is the difference regarding bitmap-handling between the two?

There is none. Please do not worry about the difference! If it is not
persistent, the code runs:

          } else if (!persistent && hotrepair) {
                hotrepair = 1;
                printk(KERN_INFO "md: forced repair of mirror component %x\n",
                        dev);
          } else {
                /* failed match */
                hotrepair = 0;


which maintains hotrepair if it has already been decided that a
hotrepair is feasible. If the array is persistent, it does the uuid and
event count tests. Either way, there are plenty of printks. You can't
avoid seeing the trace.

I have placed in

   ftp://nbd.it.uc3m.es/pub/Programs/

the following:

   linux-2.4.30-uml.tgz

(46MB) a tar of the 2.4.30 uml source tree WITH compiled "Linux" usermode
linux executable and module. And

   root_fs_toms1.7.205.small

(6MB) a root fs.

In the base dir of the  source tree you will find a "linux" executable.

If you run

  ./linux ubd0=./root_fs_toms1.7.205.small eth0=tuntap,tap0,,192.168.222.254 ro pwd=/tmp root=/dev/ubd0 ubd1=/tmp/core0 ubd2=/tmp/core1

(or similar), you should have  a working UML setup into which you log
as root (no passd). The executable runs as you, not root. Root login
does a chroot to the root of your fs mounted as /host in the uml.  So
you should see everything as it is on the outside. Even the current dir
is preserved.

Once inside, (and you need /tmp/core[01] made, but you can elaborate for
yourself), you can do

    mount -t devfs none /dev
    mdadm -C -l 1 -n 2 -x 0 /dev/md/0 /dev/ubd/[01]


then play with raidsetfaulty and raidhotadd.

You can recompile the source and add modules to taste. Arrrggh. You may
HAVE to recompile - I think your libc will be different from mine.

In that case, 

   mount -o loop root_fs_toms1.7.205.small /mnt

and replace the modules in /mnt/lib/modules with your recompilations
too. Then

   umount /mnt

and you should be ready to go.



Peter