RE : RE : Detecting directory changes.
Doing whatever F11X$POSIX_FASTRDSEQNOS does. This is one of two things - it either enqueues a lock and dequeues the lock (...) , or it directly accesses the memory structures used by the lock manager The routine actually enqueues/dequeues a lock, and does not access directly the lock manager data structures. That's true is not so FAST, but I assume it does this because it does not want too be too much dependant of the internal data structures, which are regularly changing when VMS version changes. Interesting. In that case, it is probably not actually any faster than doing it yourself. I tend to prefer notification via AST over polling. It is more efficient and should be faster I do too, but may be not in this case, because 1. doing this may interfer with internal VMS behaviour, and slow down the entire system (imagine you have a big lot of SMBD processes), I can't immagine that this would be much of a problem. You would have a few more locks in existance at any time is all. The tradeoff would be a little more memory for the lock manager and possibly slightly longer lists in the hash nodes that take a little more time to check for the lock manager, when it hits the slightly more frequent nodes with more than one entry. 2. you may end with a huge number of locks (one per directory/per SMBD process) How many different directories does you code maintain a cache for at a time for one process? It seems to me that it should maintain only a few - the most recently accessed directory and some number of previous directories, where some number could be a fixed value, controllable via the SAMBA.CONF file or a logical name, or might depend on how much memory each is using (i.e. you could limit it by memory use instead of by a specific number of directories). As I recall, Windows looks into each subdirectory when a directory is first accessed just looking for desktop.ini files, I think - I don't recall it wanting a full directory listing of each. Are individual files cached? Are the directories that a file is in cached when a specific file is looked for, or only for full directory listings? (Yeah, I know - I could look at the source, which would answer all of these questions.) I don't think the number of locks is likely to be a problem. Even on a small and fairly lightly used system there are usually thousands of locks. With 1000 SMBD processes each caching up to a maximum of 100 directories it might be a problem (which should be solved, mostly, from a simple autogen to adjust the relevant parameters to account for the additional lock usage). With 10 SMBD processes each caching up to 10 directories it wouldn't be a problem. 3. using blocking ASTs in kernel mode can be highly dangerous, because image exit does NOT dequeue those locks, so you must be absolutely sure that there is no kernel blocking AST left when you exit, unless you'll crash when trying to execute a blocking AST routine that is no more in memory. This is a concern. The code that does this should be absolutely clean and there should be an exit handler that knows how to clean the process' locks up. This is probably the strongest argument against doing it. Whether or not it is strong enough to stop you from doing it is another question. (about rewriting the F11X$ routine in C) Since this could work on a VAX, but the routine doesn't exist there, then it might be useful if you want it to work equally well on a VAX. That's true, and would make it a little less undocumented/unsupported, because it would only depend on the resource names used by the XQP, and not on the actual presence of the F11X$ routine. I'll do it as soon as I have a little time. Just be carefull. --- Carl Perkins Computer Systems Manager Geochemical Environmental Research Group Texas AM University [EMAIL PROTECTED] PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Detecting directory changes.
If another way of doing it is desired, perhaps the following could be considered. The general description of the method is to use the lock manager in a way that is compatible with how RMS uses it. What you'd do is to take out a lock in PR (protected read) mode on the RMS resource that represents the directory file. These resources have names that are built using a known pattern (4 character prefix of RMS$, 6 byte FID, 16 character devlockname). So after you read the directory data into your cache you enqueue a PR mode lock to the resource and close the file, at which time this lock should be granted (possible refinement - the lock could initially be requested in NL (null) mode with LCK$M_EXPEDITE specified, then a conversion to PR mode enqueued; this may have some advantages). You specify a blocking AST with the lock. The PR mode lock will not block any read-only access to the file, as they should PR (or maybe CR) mode locks. Any open allowing writes to the file should trigger your blocking AST as these will involve a PW (protected write) or EX (exclusive) mode lock which will be blocked by this lock. In the blocking AST you enqueue a conversion of lock to NL mode and set a flag for the cache indicating that it is invald. The next time the cache is needed the program checks the validity flag and finds that it is not valid so the cache is refreshed from disk and the lock converted back to PR mode. (Note that the resources used by the RMS locks all have a minimum of executive mode access and are all system locks. This makes enqueueing them just a bit more complicated.) The advantage is that you wouldn't need to poll the sequence number via F11X$POSIX_FASTRDSEQNOS every time you want to read from the cache, possibly giving some slight (possibly trivial) increase in performance. (Instead of polling for the value, you get notified via the blocking AST.) The disadvantage is, I think, that you had best be very carefull when messing around with RMS or you could have an adverse effect on the system as a whole. It is also possible that you will be invalidating the cache more often than is really necessary since other accesses to the directory file for reading it may not always be done in a read-only type of way (defaults for opening files in C, for example, is no sharing which presumably causes an EX mode lock to be used which would trigger the blocking AST and invalidate the cache). You should note that the Frontport library already does this sort of thing with RMS locks, thus Samba V2.0.6 is also already doing this sort of thing (and it works OK). Frontport's useage of this is, as I recall, somewhat simpler - I think it only enqueues locks to RMS resources to find out who is blocking you, and those test locks are immediately dequeued. This is part of its increase to fcntl() functionality regarding locks. It's a possibility to consider, anyway. --- Carl PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Detecting directory changes.
That's actually a way to consider, but I am not too much confident, because the problem is to know when directory contents are changed. You are talking here of RMS locks, and changes in the directories are not made by RMS, but by the XQP. I mean that there is no calls to RMS $OPEN service when changing the directory contents, so there is probably no RMS$xxx resource either to be AST blocked for that purpose. I keep forgeting that even though the $RENAME service is part of RMS, it won't take out RMS locks (at least, I'm pretty sure it doesn't). OK, I have done some research. It turns out that the XQP uses serialization locks with names with a prefix of F11B$s followed by 4 bytes of binary data that are 2 bytes of FID file number and 2 bytes of RVN/NMX data (the only example I have found doesn't use the NMX data, but it is from 1994), essentially it is the FID with the middle two bytes of file sequence number removed. This is a child lock on a volume allocation lock - a lock taken out on a resource with a prefix of F11B$v followed by 12 bytes of volume name (space filled). So instead of blocking ASTs via a (probably never used) RMS resource, you could do it on the F11B$s serialization resource. According to the only mention of this on the Ask the Wizard pages, this is used by various software, including 3rd party softwre, for doing this sort of thing. I found an old (1994) program using this (it doesn't use the NMX byte to get the full range of file numbers, instead using only the RVN byte, so it will not always work as advertised on a more modern system - it will tend to operate on the wrong file if the desired file uses the NMX bits to extend its file number past the 16 bit limit). This program was for doing something a lot like SAMBA need - it was intended to replace the scanning of the contents of a directory to see if anything had changed with a way of being notified when it changed. See: http://www.eight-cubed.com/watchdir.zip which has a parent document of: http://www.eight-cubed.com/downloads.html The lock's resoure name's format is also mentioned in a few other places such as http:// www.geocities.com/keithparris/decus_presentations/ s2002_dist_lock_mgr_perf.ppt which includes this text in an example: 'F11B$vAPP2' 202020202020202032505041762442313146 Files-11 Volume Allocation lock for volume APP2 'F11B$sH...' 0148732442313146 Files-11 File Serialization lock for file [328,*,0] on volume APP2 The a lock on the former resouce would be the parent of the lock on the latter resource. (The parent lock evidently just needs to be in NL mode.) Figuring out some of this would be easier for someone with the VMS File Systems Internals book. Unfortunately that has not been updated since 1990 and would therefore be missing some information (like the NMX bits in the FID, probably). --- Carl PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Detecting directory changes.
So instead of blocking ASTs via a (probably never used) RMS resource, you could do it on the F11B$s serialization resource That's exactly that resource that F11X$POSIX_FASTRDSEQNOS uses. The question is : is it really useful to re-write in C a routine that is already available in the system, even if it's an undocumented one ? Since this could work on a VAX, but the routine doesn't exist there, then it might be useful if you want it to work equally well on a VAX. It also switches polling the lock value block using that routine every time you want to read from the cache to something that is not polling that resource. It is going from: Doing whatever F11X$POSIX_FASTRDSEQNOS does. This is one of two things - it either enqueues a lock and dequeues the lock in a lock mode such that it gets a copy of the current lock value block, or it directly accesses the memory structures used by the lock manager to locate and read the lock value block. Since it is called FASTRDSEQNOS and direct access would probably be faster, I assume that this is what it does (probably in kernel mode). to: Checking a local variable. This variable is set by the blocking AST to indicate that the cache is invalid. This uses blocking ASTs and pays no attention to the sequence number in the lock value block. I tend to prefer notification via AST over polling. It is more efficient and should be faster: walking the lock manager's data structures (in kernel mode, I expect) to get the data in the lock value block and comparing it to the saved value vs. checking a local variable to see if it has been changed from TRUE to FALSE (or whatever) by an AST. You do still have to worry about version compatability. I would guess that this should at least work on any version of VMS that uses the XQP, but maybe not. A concern is how the other, system controlled, locks behave. If they have possible modes that indicate read or write access, then this should work well (e.g. they could use PR mode locks when reading and PW or EX mode locks when writing). If they don't (e.g. they just get set to EX mode even for a read access), then it won't work so well - it would probably require switching to using the lock value block. If that is the case, then it is not so usefull except maybe just using it to get the contents of the lock value block on a VAX (assuming that it sets this, but just not provide the F11X$POSIX_FASTRDSEQNOS routine to read it), which just requries taking out the lock and converting it back and forth between modes to get the data stored in the lock value block every time you need it. If the VAX flavor of VMS doesn't set this value block, then it wouldn't be useful on the VAX for that and would probably be slower than F11X$POSIX_FASTRDSEQNOS on the Alpha (and thus not useful there either). So the usefullness depends on the behavior of VMS's use of these locks and also whether or not the VAX version uses the lock value block to store sequence number information. --- Carl PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Performance problem (2.2.4) [long]
some of it is due to disk seek and rotational latency issues, which is why switching to walking the list by the order they are in the INDEXF.SYS file and moving some operations out of the read loop just about cut it in half. I'm not sure that it will be possible to reduce it any more as the only processing that is still going on inside the read loop is copying data, some bitwise operations (anding, oring, negating, and shifting), and a couple of adds. I may try to move everything except the data copying out of the loop, but there isn't much left to move and moving the things I did move made only a very small improvement. It is possible that it may help to only copy the data that Samba actually uses - there are fields in the stat structure that it may not need, and I'm filling them all. There are a variety of improvements that could be made to the scan_dir routines, but they are increasingly difficult to implement (especially correctly). For example, at the moment the disk I/O is done synchronously with a sys$qiow reading one block, the data is processed, then moving on to the next read. Some sort of multiple buffer with asynchronous I/O scheme could probably reduce that null time considerably. If Samba's attempts to list all the files in a directory could be switched over to this method of doing them all at once then pulling the data out of the list as it is needed and cleaning up after it is all sent, this could reduce the time it takes by maybe up to 45% if done using the current version of the routines (it wouldn't reduce file name translation or network transmission times or any other processing, so it would probably be a bit less). It would need to be modified to only attempt this for the full directory listings, not when looking for individual files (as the PC gets the listing for a directory it also sends a request for each subdirectory you sent to check it for a file called desktop.ini, for example). If all the necessary data is obtainable with it, it may also be better to directly use the RMS sys$parse and sys$search routines - I'm not sure why since I had originally assumed that this was how stat() was getting its data, but it could be doing something a lot like I am doing but just for one file at a time. RMS does do a variety of caching that might be helping its times. It is hard to say what it's times would be like if all the neccessary XABs are added to the FAB, but it will probably be slower than the scan_dir method as it is close now and already uses nearly a factor of 3 more CPU time. Potential solutions mostly involve recoding SAMBA to reduce the number of times that it calls stat(). Caching some of it may help a little - it does stat() some filespecs repeatedly. (It turns out that Samba does have a thing called a stat cache, but after looking at it I think it isn't caching the results of stat() calls. It appears to be used for some sort of translated filename caching so that it can stat() a filename without having to retranslate it, just look it up.) This also affect UNIX but not to the degree that it hurts OpenVMS. But the true fix may require significant optimizations to the UNIX code base. I suspect that doing something like I have tested could be in the realm of significant - but it is possible that this would only involve changing things is a rather small number of places in the code. I haven't checked. --- Carl Perkins Computer Systems Manager Geochemical Environmental Research Group Texas AM University [EMAIL PROTECTED]
