Re: enbd-fr1 on 2.6.11.12 problems

Hello,


What is the status of 2.6.12 kernel support in fr1?  I can't get it to 
patch with the basic 2.6.12.3 kernel.  Is there a beta/CVS version of 
the patch available that I can try?


Regards,
Carlos

Peter T. Breuer wrote:

>"Also sprach denis bonnenfant:"
>  
>
>>Well, there is a little problem :
>>when an array is started with an enbd component, it can't be stopped.
>>
>>I can manually fail nda1, and then stop the array,
>>but when there is an event causing  enbd-client to fail nda1 disk, I can't stop 
>>md0, mdadm says that device is busy,
>>    
>>
>
>Presumably some write is oustanding.
>
>  
>
>>even if enbd-client reconnects and the nda1 
>>disk gets reconstructed.
>>    
>>
>
>You'll have to check what md is complaining about.
>
>  
>
>>*Here I stop enbd-server :
>>
>>md: errors occurred during superblock update, repeating
>>    
>>
>
>Well, that's because the device is missing.
>
>  
>
>>md: write_disk_sb failed for device nda1
>>*... 200 times...
>>    
>>
>
>That is an old version of md - I recall Neil fixing that.
>
>  
>
>>md: errors occurred during superblock update, repeating
>>md: write_disk_sb failed for device nda1
>>md: excessive errors occurred during superblock update, exiting
>>
>>*Strange ? normally md has been notified that enbd-server is down ?
>>    
>>
>
>Well, it is trying to write to its superblock. I don't see any evidence
>of a notification being attempted. Presumably it hasn't been done?
>
>  
>
>>ENBD #2535[1]: enbd_enable set VALID on nda
>>    
>>
>
>Well, here the notification of reincorporation is sent, but I saw no
>notice of failure sent before. That needs investigating.
>
>  
>
>>ENBD #74[2]: enbd_notify_md_device notifying 2344 for 2b:0 to raid devices via f
>>n
>>ENBD #81[1]: enbd_notify_md_device ioctl 2344 to raid devices returned -22
>>    
>>
>
>Well, the raid array failed to accept the reincorporation.
>
>  
>
>>ENBD #74[3]: enbd_notify_md_device notifying 2344 for 2b:1 to raid devices via f
>>n
>>md0: repair of faulty disk 2b00001!
>>md0: notifying dev 2b00001 it is no longer in array
>>    
>>
>
>And here the md code tells enbd that it has been ejected from an array.
>
>  
>
>>ENBD #4162[7]: enbd_ioctl received BLKMDUNTFY, now out of raid 900000
>>md: unbind<nda1>
>>md: export_rdev(nda1)
>>md 1243: unlock_rdev nulls bdev
>>md: WARNING: delaying free of exported rdev c5b51580
>>md 1233: lock_rdev restores bdev 2b00001 rdev(c5794dc0)->bdev(cfee0580)
>>nda1 (read) [events: 000000f0]
>>md: old uuid 8b050960 a29a0ec0 39a9072f 40e47ee4
>>md: new uuid 8b050960 a29a0ec0 39a9072f 40e47ee4
>>md0: new disk 2b00001 too old for repair (disk 240 < bitmap 543)
>>    
>>
>
>Well, here something thinks it is entering the array again. But an
>intelligent repair is not done because the disk left the array way
>before the bitmap was started.
>
>  
>
>>*really strange
>>    
>>
>
>Looks normal to me. Strange things will happen if one writes random
>code.
>
>
>  
>
>>! why so much events? write errors above? nothing special happens !
>>    
>>
>
>So many events can occur, but it looks a bit random. You should check
>what mdadm says is the count on the disks and the array.
>
>  
>
>>md: bind<nda1>
>>md0: notifying dev 2b00001 it is now in array
>>ENBD #4143[8]: enbd_ioctl received BLKMDNTFY, am now in raid 900000
>>    
>>
>
>It's now been added to the array again.
>
>  
>
>>ENBD #4152[1]: enbd_ioctl set show_errs on nda
>>md0: set repair bit to 0 on superblock c5d14400
>>md0: md_check_recovery 2: repair bit 0 on sb c5d14400 preserved
>>raid1: testing p->rdev c50dd940
>>raid1: testing p->rdev->bdev cfee03c0
>>raid1: testing p->rdev->bdev->bd_dev 800001
>>raid1: testing p->rdev c5b51580
>>raid1: testing p->rdev->bdev 00000000
>>raid1: late free of exported rdev c5b51580
>>RAID1 conf printout:
>>  --- wd:1 rd:2
>>  disk 0, wo:0, o:1, dev:sda1
>>  disk 1, wo:1, o:1, dev:nda1
>>.<6>md: syncing RAID array md0)
>>md: minimum _guaranteed_ reconstruction speed: 100000 KB/sec/disc.
>>md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) f
>>or reconstruction.
>>md: using 128k window, over a total of 97152 blocks.
>>md0: no repair bit on sb so removed bitmap c5c55e00
>>raid1: synced dirty sectors 0-194303
>>raid1: synced dirty sectors 0-194431
>>    
>>
>
>Full resync, correct.
>
>
>  
>
>>md: md0: sync done.
>>bitmap: 3 pages in use
>>bitmap: 3 pages allocated
>>bitmap: 0 pages pre-allocated
>>RAID1 conf printout:
>>  --- wd:2 rd:2
>>  disk 0, wo:0, o:1, dev:sda1
>>  disk 1, wo:0, o:1, dev:nda1
>>md0: md_check_recovery 1: repair bit 0 on sb c5d14400 preserved
>>md0: md_check_recovery 2: repair bit 0 on sb c5d14400 preserved
>>
>>*end of reconstruction
>>*run mdadm /dev/md0 --fail /dev/sda1
>>
>>raid1: Disk failure on sda1, disabling device.
>>         Operation continuing on 1 devices
>>raid1: made bitmap c5c55e00 at events 0:225
>>md0: md_check_recovery 2: repair bit 0 on sb c5d14400 preserved
>>
>>*run mdadm --stop /dev/md0
>>
>>md: md0 still in use.
>>    
>>
>
>Writes outstanding, I suppose.  You need to check where that code is and
>what it is looking at. Just a question of seeing what ioctl mdadm
>issues with strace, and then looking for the return value that strace
>saw in the md code.
>
>
>Peter
>_______________________________________________
>ENBD mailing list
>[email protected]
>http://lists.community.tummy.com/mailman/listinfo/enbd
>  
>