Ok, anyone know if we're subject to the same bug as MS fixed in 95B vredir.vxd? A test, with log level 3, sound like it's in order. --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb@canada.sun.com
In your message regarding Re: TriDent (was: Safe and stable) dated Wed, 01 Mar 2000 14:20:13 -0500, David Collier-Brown said that ...> Ok, anyone know if we're subject to the same bug as MS fixed > in 95B vredir.vxd? > > A test, with log level 3, sound like it's in order.I don't *think* so. The reason I say this is that the person who discovered this vredir.vxd bug (with respect to TriDent) was the (then) programmer, Simon Craythorn <simon-c@intervations.co.uk> [http://www.intervations.co.uk], who wrote a little program to prove (to Microsoft) that the problem existed. The program consisted of a server and client module. The server module wrote a file and with each keypress incremented the file size by n bytes and output the current size and the client then reported the file size (I think this is how it works). Anyway under Win95B vredir.vxd the two frequently didn't match. My tests with this program on Samba have always given consistently correct results. However, since I am a dentist and not a programmer I don't believe that qualifies me to state that the whole thing is absolutely 100% foolproof :-). I am content for me to fill teeth and you guys do the coding. I am assured that the file locking in TriDent uses normal Windows methods and there is nothing 'idiosyncratic' about the process. The issue of oplocks is perhaps the only aspect of Samba which concerns me in this respect. Namely the possibility of the cache (for this is what I understand is provided by oplocks) failing to update should client_1 (say) write to a file and then client_2 not 'see' the update but only what has been cached (you can tell I'm not a programmer by now :-) ). Now I don't really want to turn oplocks off since I understand that this would lead to a significant drop in performance but would really like to know what effect it could have in this situation (I have got your book, David, and have read the Samba documentation and only 90% of it went totally over my head ;-) ). I have now moved the database over to Samba from its situation on a Win98 peer and BTW noted by wishful thinking or imagination a significant improvement in the speed at which the data arrives at the client (in the case of TriDent). I *am* using log level 3, and my question remains "what errors am I looking for?" - I have only seen one oplock error so far and that was related to a M$ Excel document! Also of interest is that I am currently co-authoring an article (or series of) for a dental professional publication on the advantages of using Linux in the Dental Practice environment as an alternative to Windows NT server (about UK£700 worth of advantage and a lot more fun!) Thanks for your help so far. -- Mike Bostock Home: mike@yew-tree.co.uk Work: mike@wistaria.co.uk Work Tel: 01363-773377 Fax: 01363-777729 (Office Hours) http://www.toothfairy.co.uk/
You wrote: | I have now moved the database over to Samba from its situation on a Win98 | peer and BTW noted by wishful thinking or imagination a significant | improvement in the speed at which the data arrives at the client (in the | case of TriDent). Spiffy! | I *am* using log level 3, and my question remains "what errors am I | looking for?" - I have only seen one oplock error so far and that was | related to a M$ Excel document! The things I'd watch out for are: 1) oplock breaks on the samba side 2) diagnosis of locking failure on the client side, such as "can't access/lock xxx" -type messages 3) actual data overwrite errors in the trivial test: have two folks update the exact same field. Once you've tried the trivial test, turn your logging back down: log level = 3 slows down Samba a lot! | Now I don't really want to turn oplocks off since I understand that | this would lead to a significant drop in performance but would really | like to know what effect it could have in this situation Sure: in the case of exactly one user using the database's data files, they would be cached locally on that person's client. This causes a performance improvement. In the normal multi-user case, the first client gets an oplock, caches the file, and as soon as the second user comes along, gets an oplock break and has to write-back the cache, wasting time. After that, the two (or more) users access individual chunks of the file from the server, with no caching, but under control of windows byte-range locks. I'd mildly recommend making just the share that the database is on non-cached (oplocks = no), as it will save on wasted attempts to cache, and not hurt performance if you have more than one user. --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb@canada.sun.com