Thank you very much, that did the trick. I will remove sg3_utils package now. Hopefully this will never happen again. I had to remove SCSI reservations from 4 different volumes. Any suggestions on how to avoid this in the future? We were planning on using SCSI fencing in combination with APC Power Switches, I am not sure this is such a good idea after this experience? Any additional thoughts?
On Thu, Feb 19, 2009 at 11:34 AM, Ryan O'Hara <[email protected]> wrote: > On Thu, Feb 19, 2009 at 11:07:12AM -0600, Alan A wrote: > > > > Thank you Ryan. This was totally correct - yet it will not let me remove > the > > reservation. Here is the output of several commands I tried: > > > > [r...@fendev04 ~]# sg_persist -o -C -K 0xb0b40001 /dev/gfs_acct61/acct61 > > HP OPEN-V 6002 > > Peripheral device type: disk > > persistent reserve out: scsi status: Reservation Conflict > > PR out: command failed > > > > --------- > > Ok. The trick is that you have to attempt to clear the reservations > from a node that is registered with the device. In other words, being > registered with the device is a prerequisite for doing certain > operations, like clearing reservations and what-not. > > > > [r...@fendev04 ~]# sg_persist -i -k /dev/gfs_acct61/acct61 > > HP OPEN-V 6002 > > Peripheral device type: disk > > PR generation=0x2, 2 registered reservation keys follow: > > 0xb0b40001 > > 0xb0b40003 > > So we have 2 keys registered. We'll call 'em 0001 and 0003. Those > lower 32-bits are generated from the nodeid defined in cluster.conf, > so if explicitly set the nodeid's in the config file, this should help > determine which node is associated with each key. > > > [r...@fendev04 ~]# sg_persist -i -r /dev/gfs_acct61/acct61 > > HP OPEN-V 6002 > > Peripheral device type: disk > > PR generation=0x2, Reservation follows: > > Key=0xb0b40001 > > scope: LU_SCOPE, type: Write Exclusive, registrants only > > The reservation holder is 0001. That looks fine. > > Just out of curisousity, I see that that commands you were running > were from a machine named 'fendev04'. Would that happen to be nodeid > 4? If so, I'm guessing that the node you are trying to run the > commands form is not registered with the device. Run the same command > (sg_persist -o -C ...) from a different node (ie. one that is still > registered with the device) and it should work. > > -- > Linux-cluster mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-cluster > -- Alan A.
-- Linux-cluster mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
