| Newsgroups |
gmane.linux.enbd.general |
| Message-ID |
<[email protected]> |
Citando [email protected]:
> Send ENBD mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.community.tummy.com/mailman/listinfo/enbd
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ENBD digest..."
>
>
> Today's Topics:
>
> 1. Re: Re: patch fr1-2.17 does not work with kernel 2.4.30
> (Stephan von Krawczynski)
> 2. Re: Re: patch fr1-2.17 does not work with kernel 2.4.30
> (Stephan von Krawczynski)
> 3. Re: Re: patch fr1-2.17 does not work with kernel 2.4.30
> (Peter T. Breuer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 11 Apr 2005 13:24:11 +0200
> From: Stephan von Krawczynski <[email protected]>
> Subject: Re: [ENBD] Re: patch fr1-2.17 does not work with kernel
> 2.4.30
> To: [email protected]
> Cc: Enhanced Network Block Device <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII
>
> On Sun, 10 Apr 2005 19:59:51 +0200 (MET DST)
> "Peter T. Breuer" <[email protected]> wrote:
>
> > Try changing 27 to 26. Recompile all md modules.
>
> I tried that, but that did make no difference at all. All output looks quite
> the same and the "hotadd" is a complete resync.
> Still there is no call to bitmap->start. The output still tells me that the
> bitmap XXXX is "already active!". This is the code right before
> bitmap->start.
> It seems never "started" but always "active", right from the beginning ...
>
> Regards,
> Stephan
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 Apr 2005 15:07:56 +0200
> From: Stephan von Krawczynski <[email protected]>
> Subject: Re: [ENBD] Re: patch fr1-2.17 does not work with kernel
> 2.4.30
> To: [email protected]
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 11 Apr 2005 13:36:04 +0200 (MET DST)
> "Peter T. Breuer" <[email protected]> wrote:
>
> > "Also sprach Stephan von Krawczynski:"
> > > On Sun, 10 Apr 2005 19:59:51 +0200 (MET DST)
> > > "Peter T. Breuer" <[email protected]> wrote:
> > >
> > > > Try changing 27 to 26. Recompile all md modules.
> > >
> > > I tried that, but that did make no difference at all. All output looks
> > > quite the same and the "hotadd" is a complete resync.
> >
> > There's no point in looking at that. Confirm the call to start.
> >
> > > Still there is no call to bitmap->start.
> >
> > I'm afraid there is! I showed you my trace:
> >
> > md: set_disk_faulty
> > md: md_error
> > raid1: raid1_error
> > raid1: mark_disk_bad
> > raid1: raid1_start_bitmap
> > raid1: made bitmap a027dc20 at events 7
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > raid1: Disk failure on ubd/disc2/disc, disabling device.
> > Operation continuing on 1 devices
> >
> > The sequence is directly executed from hotsetfaulty.
> >
> > > The output still tells me that the
> > > bitmap XXXX is "already active!".
> >
> > Then it has been started some time in the past.
> >
> > > This is the code right before bitmap->start.
> > > It seems never "started" but always "active", right from the beginning
> ...
> >
> > It does not seem - it is started. If the test says it is already
> > active, then that is GOOD. There is nothing wrong. You can see:
> >
> > static int
> > raid1_start_bitmap (mddev_t *mddev) {
> > ...
> >
> > if (bitmap->active(bitmap)) {
> > printk(KERN_WARNING "raid1: bitmap %x already active!\n",
> > (unsigned) bitmap);
> > return 0;
> > ^^^^^^^^^ SUCCESS!
> > }
> >
> > 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.
>
> Hello Peter,
>
> 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.
> But what I really do not understand is this:
> Why does the same hardware (and software) show this in non-persistent case:
>
> 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 25679900 blocks.
> kernel: md0: retained bitmap f6e57180
> kernel: raid1: skipped clean sectors 0-51359799
> kernel: md: md0: sync done.
>
> 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
> kernel: raid1: synced dirty sectors 0-51359615
> kernel: md: md0: sync done.
>
>
> 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.
>
> Where is the difference regarding bitmap-handling between the two?
>
> Regards,
> Stephan
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 11 Apr 2005 17:02:00 +0200 (MET DST)
> From: "Peter T. Breuer" <[email protected]>
> Subject: Re: [ENBD] Re: patch fr1-2.17 does not work with kernel
> 2.4.30
> To: "Enhanced Network Block Device" <[email protected]>
> Message-ID: <[email protected]>
>
> "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
>
>
> ------------------------------
>
> _______________________________________________
> ENBD mailing list
> [email protected]
> http://lists.community.tummy.com/mailman/listinfo/enbd
>
>
> End of ENBD Digest, Vol 17, Issue 7
> ***********************************
>