Re: init scripts problems ?

"Peter T. Breuer" <[email protected]>
Newsgroups gmane.linux.enbd.general
Message-ID <[email protected]>
"Also sprach denis bonnenfant:"
> >         if (do_media_check) {
> >                         // PTB this invalidates buffers, if necessary
> >                         ENBD_INFO ("DISK CHECK wanted in open on device nd%s\n",
> >                                 lo->devnam);
> >                         lo->last_checked = jiffies;
> >                         check_disk_change(inode->i_bdev);
> >         }
> 
> this may be a problem, as enbd device may not be partitionned !

That's alright - there's no problem with that. Look at the entries in
/proc/partitions - they include whole disk. 


I can't recall exactly what the kernel's check_disk_change() does. I'll
have to look.

It appears to call enbd_media_changed():

/*
 * This is called by the kernel (via check_disk_change) whenever it 
 * opens the superblock of a FS. And we call it whenever there is
 * an open of the device (provided we haven't already checked recently,
 * as recorded by last_checked). Return 0 for no change and 1 for
 * change.
 */
static int
enbd_media_changed(struct gendisk *disk) {


It appears to be a harmless check for readability of the remte medium.
But it bears thinking about when it is appropriate to fire it off. At
startup one can't read the remote medium because the dameons aren't up
and running yet. It seems funny to potentially fire it off at each
open, because the daemons must open the device first. It seems
intrinsically likely that there is some sort of race cndition there!
Maybe two openers at once is required to trigger it.



> just for information, from syslog of the production server : not very useful, i'm afraid to
>   but that's the only thing that i can do before setting up  my test machine !
> 
> then the problematic one, with nda and ndb  connected simutlaneously
> (and unusable):

Two DIFFERENT devices? Then how can the race be in the open?

> Nov 28 10:12:39 ldap enbd-client: enbd-client: client (0) got a signature ok from se3-croise:12356
> Nov 28 10:12:39 ldap enbd-client: enbd-client: client (0) begins main loop

Looks OK.

> Nov 28 10:12:39 ldap kernel: ENBD #824[5]: enbd_open DISK CHECK wanted in open on device nda
> Nov 28 10:12:39 ldap kernel: ENBD #4404[5]: enbd_media_changed MEDIA CHANGED called

Here the media check is triggered.

> Nov 28 10:12:44 ldap kernel: ENBD #4460[8]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on ndb
> Nov 28 10:13:04 ldap enbd-cstatd: enbd-cstatd: sending SIGPWR to live client A-2 (process 6387)

Oh - the server is telling us that it has restarted and wants to
renegotiate. Yes, that is a little inconvenient, but shouldn't be a
problem. We restart.


> Nov 28 10:13:28 ldap kernel: ENBD #3607[1]: do_enbd_remote_ioctl remote ioctl cdcd3334 found on dev queue
> Nov 28 10:13:28 ldap kernel: ENBD #3627[1]: do_enbd_remote_ioctl timed out remote ioctl cdcd3334 cleaned up
> Nov 28 10:13:28 ldap kernel: ENBD #4429[1]: enbd_media_changed REMOTE CHECK remote is down!
> Nov 28 10:13:28 ldap kernel: ENBD #4508[2]: enbd_revalidate REVALIDATE called on ndb
> Nov 28 10:13:28 ldap kernel: ENBD #4540[1]: enbd_revalidate set VALID on ndb
> Nov 28 10:13:28 ldap kernel: ENBD #4508[3]: enbd_revalidate REVALIDATE called on ndb
> 
> At this point, all the nbd devices were stuck, i tried to kill them with differents signals :

NOOOOO. DOn't. Echo 0 to /proc/nbdinfo. And before you do that, show
the ps WCHAN entry.



Peter
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.