[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

377.0. "Disk shadowing => uses twice the number of locks (ENQLM) ?" by RDGENG::WOOD_J ([email protected]) Tue Mar 25 1997 07:44

Does disk shadowing have any effect on the number of locks a process
might need?

I.e. it's conceivable that if a file is duplicated on a shadow disk,
that the application might need to take out locks for each disk. This
would mean that a process's ENQLM might need to be increased if
it's accessing shadowed disks.

I wouldn't imagine that disk shadowing does affect lock usage.
However, a software vendor has a lock problem which only shows up
using shadowed disks.

Thanks,
  John

T.R	Title	User	Personal Name	Date	Lines
377.1		UTRTSC::16.198.64.201::JurVanDerBurg	Change mode to Panic!	`Tue Mar 25 1997 08:04`	7
	No, shadowing works at LBN level so no additional locks are used. Do you have more info about the lock problem? Increased usage? Error messages? Jur.
377.2	Further Info On Package?	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Tue Mar 25 1997 09:05`	10
	I wouldn't imagine that disk shadowing does affect lock usage. :However, a software vendor has a lock problem which only shows up :using shadowed disks. In addition to .1, what's the vendor's software package doing? (Is it a standard application, or is it trying to do something unusual with the low-level file structure or volume locks, etc.?) And is the system seeing the problem(s) SMP? (SMP systems tend to uncover race conditions in application code...)
377.3	thanks	RDGENG::WOOD_J	[email protected]	`Tue Mar 25 1997 10:30`	13
	Thanks for the replies. There's a suspicion that the process might be running out of locks. The s/w vendor has his own locking routine which calls $ENQW. He says it "sometimes fails". I've suggested he check the status returns from $ENQW & call LIB$SIGNAL if it's a bad status, so we can see why it's failing. He hasn't done this yet... It could be that the shadowed system has lower lock limits (ENQLM) that other systems. John
377.4	Beware	STAR::EVERHART		`Tue Mar 25 1997 11:43`	10
	Remember too that if the vendor is apparently trying to do shadowing without using a different device name, it is exceedingly likely that he will run into a dkdriver behavior (alpha 6.2 on) that will corrupt the shadowsets. There have been other reports with asci packages like this quite apart from this problem, btw, on DECUSERVE but in general on alpha vms 6.2 and later, an intercept of I/O at dkdriver start_io will NOT always see all IRPs. Locking errors in a shadow package sound very strange...
377.5		EVMS::MORONEY		`Tue Mar 25 1997 12:13`	4
	Shadowing does use several locks internally, but these are _system_ locks and will not affect a process lock limits and are not charged to a process. These locks are created when the shadowset is mounted and the number is constant, not affected by file activity.
377.6		MOVIES::WIDDOWSON	Rod OpenVMS Engineering. Project Rock	`Tue Mar 25 1997 12:54`	16
	I just dig the `sometime fails'. It is so informative (of your customer John, not you). Mind you I suppose it could have failed with the ever helpful SS$_EXQUOTA, then the egg would be on my face ;-) Seriously, in order to find out more about what is going on the precise semantics of `sometimes failing' would be useful. For instance as a stupid example: Assume that the user requires that the $ENQ return within a fixed time but that with shadowing, the round trip delay (to get the R0 completion AST which in turn causes the $ENQ to return) goes up because there is a shadow merge happening and there is only an overloaded ethernet for it to go over... So we all await the customer doing your LIB$SIGNAL...