RE: I can not print with my network printer
> So I guess the mailing list "General questions regarding Samba" would be > the right one? correct PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE: I can not print with my network printer
Serando, You seem to have misread (or missed entirely) the purpose of this mailing list, which is: General discussion between people interested in using or developing Samba on hp's VMS operating system. You seem to have a problem involving Samba and VMs, not VMS (aka OpenVMS; see https://en.wikipedia.org/wiki/OpenVMS ), an entirely different topic. I'm afraid we can't help you here with that. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Non-SMB packet of length 0. Terminating server
I am using a Linux smbfs client (version 3.0.25a) with a VMS Samba 2.2.8
server (20050817 + misc patches from JYC). I am periodically getting
these errors in my smbd log for this client, and when that happens, the
file that the application had open remains open indefinitely (or at
least until the smbd instance is terminated).
[2007/06/18 13:13:02, 0]
DISK$SWAP:[JYC.SAMBA.SAMBA-2_2_8-SRC.SOURCE.SMBD]PROCESS.C;2:(662)
Non-SMB packet of length 0. Terminating server
I see in smbd/process.c:
/* make sure this is an SMB packet. smb_size contains NetBIOS header
so subtract 4 from it. */
if ((strncmp(smb_base(inbuf),\377SMB,4) != 0) || (size
(smb_size-4))) {
DEBUG(0,(Non-SMB packet of length %d. Terminating
server\n,smb_len(inbuf)));
exit_server(Non-SMB packet);
return(-1);
}
I wonder if this is due to an incompatibility between my much more
recent client and the aging 2.2.8 server? I would sure like to have
these systems talk to each other. Is there any way around the problem?
Ben
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
Re: ODS-5 issues: broken utime
John E. Malmberg wrote: For HP Samba V3 evaluation release, it should be currently using the CRTL utime(). That's what I figured. DECC$EFS_FILE_TIMESTAMPS causes different fields in on an ODS-5 volume to be exposed by the CRTL. These fields more closely track what UNIX expects. There are also volume settings that need to be made, and increasing the resolution of the timers can impact file system performance. As some Perl scripts may be expecting traditional OpenVMS behavior, for the normal running of Perl, there is no reason to force a setting of DECC$EFS_FILE_TIMESTAMPS. Wouldn't Samba be quite a different matter, then? I'd expect most applications that use VMS Samba would be running on non-VMS systems, so non-VMS semantics are perfectly appropriate. So it sounds like setting DECC$EFS_FILE_TIMESTAMPS would be a good thing. I do not understand this issue. If the directory is invisible, then that should be hiding the files. They still should be accessed explicitly by path name though. If I performed an ls on a hidden directory explicitly referenced by path name (e.g. ls .hidden,) no files would be found! The only way I could see files in it was to perform ls on each file explicitly (e.g. ls .hidden/foo .hidden/bar). This is an issue where the CRTL unlink() works differently than the UNIX unlink(). The UNIX unlink() only pays attention to the write permissions on the directory where the file resides, not the permissions on the file it self. Right. I understand why it has to work that way. But what I do question is whether Samba should be aware of the D bit at all. Just as x is forced on for all files served from a samba share on a Windows host because Windows has no concept of x, why shouldn't D be either ignored or forced on? Currently the only known work around is to place an ACL on the file to always allow delete by the application. See the PERL vms.c source where it adds a temporary ACL on the file to attempt to delete it. Perl has the advantage of being able to add ACLs as needed. However, when a samba client application creates a read-only file, how is it supposed to make the file deletable? Also the implementation of the DOS readonly attribute can not be properly implemented on OpenVMS and possibly on UNIX. That hasn't caused me problems ... yet. I'm not complaining that DOS readonly doesn't map properly. I just don't understand why chmod 444 (or even chmod 000) must be interpreted as removing the D bit, given the undesirable semantics that result. After all, if the client doesn't even know the D bit is there, why should chmod do anything with it at all? If a samba client really needs to prevent files from being deleted, it can be done in the usual way, by taking away write permission from the directory on which the files reside. All in all, implementing the READONLY attribute as an ACL is probably the best compromise for functionality, as long as it is realized that the ACL may not be honored on the OpenVMS host the same way that a Microsoft Windows system. Sounds good if it all works transparently. But this would have to be managed by Samba itself. It's a bit beyond me to make such extensive changes. Does the DECC$RENAME_NO_INHERIT fix this? Even if it does (and it seems like it should) it is a 7.3 feature, right? Since JYC's Samba supports 7.1 and greater, it doesn't seem like something we can rely on. Have you seen any of these issues with the HP Evaluation release? In an ideal world, we'd have time to evaluate the HP Evaluation release alongside JYC's 2.2.8 release. However, it doesn't look like it's close enough to being ready for production use to grab our interest at this time. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Error: failed to change delete on close flag in 2.2.8 (JYC 17-Aug-05)
Hi, Is anyone else seeing these in SAMBA_LOG logs? [2005/08/26 08:53:12, 0] DISK$SWAP:[JYC.SAMBA.SAMBA-2_2_8-SRC.SOURCE.SMBD]TRANS2.C;9:(2229) set_delete_on_close_internal: failed to change delete on close flag for file Dymax/020005/VIM2E.tmp [2005/08/26 08:53:21, 0] DISK$SWAP:[JYC.SAMBA.SAMBA-2_2_8-SRC.SOURCE.SMBD]TRANS2.C;9:(2229) set_delete_on_close_internal: failed to change delete on close flag for file Dymax/020005/VIM2E.tmp [2005/08/26 08:53:21, 0] DISK$SWAP:[JYC.SAMBA.SAMBA-2_2_8-SRC.SOURCE.SMBD]CLOSE.C;11:(165) close_normal_file: failed to change delete on close flag for file Dymax/020005/VIM2E.tmp The user is merely trying to edit a file. Cream (our PC text editor, used to edit files on a Samba share) warns that the file is not writable and asks the user to open anyway or cancel. If a different user tries to edit the same file, the error is not thrown. When I try to get the first user to edit the same file again, the error persists, and more error messages are logged in their log file. We had the same problem running one of our Ruby benchmark programs that opens, writes to, and then deletes a temporary file. The delete threw an error. Also, in DOS shell the delete threw an Access denied error. The log entries look quite similar: [2005/08/25 09:17:37, 0] DISK$SWAP:[JYC.SAMBA.SAMBA-2_2_8-SRC.SOURCE.SMBD]TRANS2.C;9:(2229) set_delete_on_close_internal: failed to change delete on close flag for file dm/BENCH.TMP [2005/08/25 09:17:45, 0] DISK$SWAP:[JYC.SAMBA.SAMBA-2_2_8-SRC.SOURCE.SMBD]TRANS2.C;9:(2229) set_delete_on_close_internal: failed to change delete on close flag for file dm/BENCH.TMP [2005/08/25 09:17:45, 0] DISK$SWAP:[JYC.SAMBA.SAMBA-2_2_8-SRC.SOURCE.SMBD]CLOSE.C;11:(165) close_normal_file: failed to change delete on close flag for file dm/BENCH.TMP Not all files are affected. The users experiencing errors can edit some other files and delete files successfully. This all looks vaguely familiar. Has some patch been accidentally left out of this version, or is this some new problem? Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Error: failed to change delete on close flag in 2.2.8 (JYC 17-Aug-05)
On Fri, 2005-08-26 at 10:44 -0300, BG - Ben Armstrong wrote: If a different user tries to edit the same file, the error is not thrown. When I try to get the first user to edit the same file again, the error persists, and more error messages are logged in their log file. Just to clarify, in one test, both the person who initially reported the problem and a 2nd tester had the same error on the same file, but when I tested it, there was no error for me. But then again, they're both Windows users and I'm a Linux user. However, I don't know if that is significant. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE: Error: failed to change delete on close flag in 2.2.8 (JYC17-Aug-05)
On Fri, 2005-08-26 at 11:01 -0400, Robert F. Thomas wrote: Without knowing the various user's rights and the various protections and ACL's no reasonable response is possible. For example one user can have RWED access and another only RW access, i.e. they can create files but not delete them. Sorry I wasn't clear, but this is not a permissions problem. All of the file permissions are correct and grant everyone in our group read, write delete permissions. There are no ACLs on these files, either. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: RE : Vim detects a file on a VMS Samba share has changed when it has not
On Mon, 2005-04-04 at 12:02 +0200, COLLOT Jean-Yves wrote: I think that differences 1 and 2 are caused by the fact we don't have the exact same version of vim, and/or we do not have the exact same cream configuration. I suggest to Ben to try with vim alone (i.e. without the cream layer) to see what happens (check that the behaviour is the same as mine). I tried with Vim alone. The bug is not reproducible. I don't understand difference 3. It could be some privilege or file protection issue. However, I try with users without any privileges, and my file protection, as far as I know, are the same as Ben's, and I can't get the same results. Could you give me all the details about the file protections and the characteristics of your users? Users are all unprivileged and belong to the [dv,*] group. Nightly, a generic dymax user (also unprivileged) handles batch processing of our task files. Thus, on a typical morning when I'm deciding what to do for the day, my task file initially is owned by [dv,dymax]. Several seconds after I start editing this file with Cream, the warning message is triggered. If I write the file, it becomes owned by [dv,bg] (my vms uid) and no further warnings appear. If I subsequently edit this file now owned by [dv,bg] the warning no longer appears. Also, if, before I start editing, I change the ownership alone (e.g. by set file/own=bg from a privileged account) and edit it (i.e. without first changing the file type from Variable to Stream) the warning no longer appears. So far as I can see, ownership is definitely a factor. If we can't find the reason, I plan to give to Ben a modified module that will do more logging about the modification time reset processing. That would be helpful, thanks. I'll have to wait for Rod to finish his vacation before installing it, though. He's coming back a week from tomorrow. So, if I have time, I'll see what else I can do to try to isolate the problem and/or make it reproducible for you this week. Thanks, Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: SAMBA problem report - file deletion failure
On Tue, 2004-12-14 at 15:21 -0400, RR - Rod Regier wrote: Sample files created using both DOS window and GUI, and deleted using both DOS window and GUI. Confirming message and file display removal occurred normally with the GUI. Subsequent DIR or GUI view refresh showed the file had in fact *not* been deleted. Jean-Yves, I believe this is another manifestation of the same problem involving the VB script that wasn't deleting lock files which I had previously discussed with you in private email. So with this new info from my colleague, Rod, it appears the problem is reproducible with standard components, and has nothing to do with VB per se. As usual, if there is some way we could make the root cause of the problem more visible, I'm all ears. (I've been trying for months to phase in the use of certain PC-based product development and support tools in our department, but because of various faults in the Samba filesystem layer, I have been thwarted at every turn. If this last obstacle could be removed, I'd be on top of the world. :) Regards, Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: SAMBA share access problem report (Dymaxion 17=17275)
On Thu, 2004-10-28 at 13:05 +0200, COLLOT Jean-Yves wrote: Now that I know that the problem appears only when the McAfee antivirus is there, I could fix it. I am sending a corrected version of the OBJ files directly to Rod, a DIFF of the sources directly to John, and I'll include the fix in the next release. Thanks for the fix. Looks good so far. Now I can report a second problem, which I had hoped was just another manifestation of the first, and therefore would be fixed by this patch. Unfortunately, it was not. The trouble is, on the same new machines that have the antivirus product on them, we have an app that creates a lock file on an OpenVMS Samba share, and then fails to delete it afterwards. The leftover lock file prevents further accesses to the resource it is locking until it is manually removed. The app is written in VB, and only fails on these new machines, not the old ones. At this point I can't tell if the fault is also related to the antivirus product or not: I have an open call to our own PC support guys to do some further testing. I know that's not a lot of info to go on. But does anything come to mind? Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Plenty to do for volunteers, On the job self training available.
On Wed, 2004-09-29 at 11:19 -0500, John E. Malmberg wrote: Help is needed at all levels of expertise. I'd like to point out to would-be contributors that before I started working on our issues with deploying OpenVMS Samba here at Dymaxion, I knew absolutely nothing about the topic. I have not received formal training in either the inner workings of filesystems or networking. All I had going for me was a desire to explore, and some guesses at how to devise tests that would narrow down the problem and make it reproducible for the developers. So, don't think you can't contribute anything because you're lacking in expertise specific to the field. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Our more serious issue: two kinds of Samba read corruption
On Mon, 2004-09-27 at 23:25 -0400, John E. Malmberg wrote: BG - Ben Armstrong wrote: - show process/acc on the user's smbd process show proc/acc/quota may provide mroe information. I'll keep that in mind. Accounting information: Buffered I/O count:193317 Peak working set size: 14640 Direct I/O count: 44366 Peak virtual size: 184880 What is the physical memory + pgflquo for the process? Is it equal or close to 184880? The SMBD processes are apparently owned by SYSTEM. That account is configured like this: UAF sho system Username: SYSTEM Owner: SYSTEM MANAGER [snip] Maxjobs: 0 Fillm: 300 Bytlm:65536 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 128 JTquota: 4096 Prclm: 20 DIOlm: 384 WSdef: 256 Prio:4 ASTlm: 410 WSquo:16384 Queprio: 0 TQElm: 100 WSextent: 2 CPU:(none) Enqlm: 2048 Pgflquo: 20 But I have also reproduced the problem on a test system which has a much higher Pgflquo (50) for SYSTEM: Maxjobs: 0 Fillm: 100 Bytlm:64000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 150 JTquota: 4096 Prclm: 20 DIOlm: 150 WSdef: 2000 Prio:4 ASTlm: 250 WSquo: 4000 Queprio: 0 TQElm: 100 WSextent: 16384 CPU:(none) Enqlm: 2048 Pgflquo: 50 I am providing JYC with a large zipped backup saveset of a directory full of files that reproduces the problem. I'm thinking it might be significant that we keep our SMBD processes around for a very long time because people didn't like having to wait for their SMBD process to come into existence: deadtime = 480 Is if possible that the process ran out of virtual memory? If so, then the next step is to try to determine where the memory leak is. I don't think so. I don't see memory usage growing. I'm hoping that the with the saveset I have provided JYC, he'll be able to finally track this one down. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Our more serious issue: two kinds of Samba read corruption
On Thu, 2004-09-23 at 14:17 -0300, BG - Ben Armstrong wrote: We have been noticing that using MS Wordpad, COPY, or other means to read the contents of a file, most of the time the file is successfully retrieved, but sometimes it returns empty. This happens on a fairly regular basis, so with proper direction, we ought to be able to catch it in the act and report more details here. So, what should we be looking for? Should our log levels be elevated, and if so, how high? Is there anything else we can do to make this problem more visible? With regards to this problem, today we collected some observations during an incident: - backup/ignore=interlock made of all .tdb files - show process/acc on the user's smbd process - show device/files for files open by the user's smbd process - dir (on the Windows client) showing zero blocks for most (but not all) files in the problem directory - dir (on the Windows client) after killing off the user's smbd process showing that all files in the problem directory now all have expected sizes I will provide all of these in a zip archive to JYC for closer examination. For the rest of us, I include below the show process show device output, in case anything looks suspicious: 27-SEP-2004 14:54:26.45 User: SYSTEM Process ID: 0001DA0F Node: DYMA Process name: SMBD_DMPCXP_DA0 Accounting information: Buffered I/O count:193317 Peak working set size: 14640 Direct I/O count: 44366 Peak virtual size: 184880 Page faults: 1009 Mounted volumes:0 Images activated: 3 Elapsed CPU time: 0 00:01:53.01 Connect time: 0 08:54:26.07 Soft CPU Affinity: off SMBD_DMPCXP_DA0 0001DA0F [SYSCOMMON.SYSEXE]RIGHTSLIST.DAT;3 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]MESSAGES.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.BIN]SMBD_STARTUP.COM;9 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.BIN]SMBD.EXE;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.PRIVATE]SECRETS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]CONNECTIONS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]BRLOCK.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]LOCKING.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]PRINTING.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]NTDRIVERS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]NTPRINTERS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]NTFORMS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]SHARE_INFO.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SYS0.SYSMGR]SMBD_STARTUP.LOG;124 SMBD_DMPCXP_DA0 0001DA0F [SAMBA]LOG.DMPCXP;1 Unfortunately, I didn't think to save [samba]log.dmpcxp itself. I'm kicking myself for that now. That might have been interesting. I'm thinking it might be significant that we keep our SMBD processes around for a very long time because people didn't like having to wait for their SMBD process to come into existence: deadtime = 480 Setting your deadtime as high as ours, and/or keeping a process busy making continuous accesses over a long period of time may help reproduce the problem. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug report (12=17020 TC029) SAMBA 2.2.8 release 20040908 - intermittent content loss
On Thu, 2004-09-23 at 23:38 -0400, John E. Malmberg wrote: Please take a look at the resulting file with a dir/full. There needn't be a resulting (i.e. output) file for this bug to manifest. The corruption is seen in the Perl program as the files are being *read*, not written. Likewise with the recurrence of the bug in Araxis merge. It seems, though I have not yet done a complete survey of a large enough sample to be 100% certain, the files being read are all Variable length record format, and not Stream or Stream-LF. I am still trying to get familiar with this code, but I am finding references to special handling if SAMBA detects that it is a VMS text file. Any VMS file that is not a stream or a fixed record size file may get corrupted by an out-of-order transfer through SAMBA as the seek() function will not go to the correct place on a write. OK, so far this is consistent with our test results. We'll let you know if we discover corruption in other file types, e.g. Stream or Stream-LF files. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug report (12=17020 TC029) SAMBA 2.2.8 release 20040908 - intermittent content loss
On Fri, 2004-09-24 at 10:40 -0300, BG - Ben Armstrong wrote: I am still trying to get familiar with this code, but I am finding references to special handling if SAMBA detects that it is a VMS text file. Any VMS file that is not a stream or a fixed record size file may get corrupted by an out-of-order transfer through SAMBA as the seek() function will not go to the correct place on a write. OK, so far this is consistent with our test results. We'll let you know if we discover corruption in other file types, e.g. Stream or Stream-LF files. Oops, I misread that as seek() ... on a read, but you said on a write. Since we're seeing the corruption before any output is written, your observations are *not* consistent with our test results. So it remains a puzzle. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug report (12=17020 TC029) SAMBA 2.2.8 release 20040908 - intermittent content loss
On Fri, 2004-09-24 at 10:22 -0400, John E. Malmberg wrote: The reason that I said on a write() is that I have only observed the segmented out of order transfer on a write. On a read, I would look for other causes. It still could be a seek() issue. It also could be that because SAMBA VMS estimated the size of the transfered data wrong, and the client believed it. My guess is that if you do not use VFC file types the problem will go away. That may prove difficult to carry off considering the large number of files in a variety of different directories involved on our production system, and our continued inability to reproduce this bug in a test environment. As for reporting the bug upstream for tracking purposes, I leave that at the discretion of the developers here, as it is of much less value to us as it is to them. It is easier for me to keep my bug reporting of VMS- specific Samba issues to this one list. If you can make a compelling case against this approach, though, I'll consider changing my habits. I just don't want to find myself in the position of taking the extra time to write bug reports to bug tracking systems that nobody reads, and that I will certainly never refer to myself, either. Thanks, Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Samba improvements needed (was: WinXP-Linux samba server test)
On Tue, 2004-09-21 at 08:32 -0500, John E. Malmberg wrote: Tcpdump, which is available for TCPIP 5.4, can read it. For example: $ tcpdump==$sys$system:tcpip$tcpdump $ tcpdump -vr test.cap I do not have a LINUX system running at this time. Three years in my new house, and I have not had time to organize that section of the basement to get one of now ancient 100Mhz/90 Mhz sytems wired up to the LAN let alone running LINUX. Well, in the meantime, do try the OpenVMS implementation of tcpdump, if you have TCPIP 5.4. It may be a difference between Samba 2.2.8 and later versions. A quick way of setting up a Samba 2.2.8 server would be to find a live CD version of Linux with Samba 2.2.8 on it. There are plenty of live CD Linux ISOs out there to burn. I favour Knoppix, but that may be too recent, since I believe they start with Debian/unstable then tailor it with the Knoppix-specific stuff. And it is not preallocation that SAMBA is doing as noted below. Oh? It sure looked like it ... The client does tell the SAMBA server how big to make the file, but not when VMS can do it efficiently. First it has the server open the file for write access, and then it uses ftruncate() or other means to extend it. Most of these move the highwater mark of the file, unlike just allocating space. And that means that the now empty file must be totally written to disk. What's the distinction between this and preallocation? Is it that the client does the file extending writes in small increments, whereas preallocation would do it all at once? It does seem that even in the WinXP - Linux case where all of the extending single-byte writes were done up front, there were way too many of them. I could well imagine that this performs poorly on OpenVMS given my (admittedly limited) understanding now of the hit we take for each preallocation. The worst run of them in my capture log started at offsets 1058815, 1059839, 1060863, etc. (i.e. 1024 byte increments) all of the way up to 2269183 before writing actual data blocks again, taking a total elapsed time of 0.94 sec. If this strategy had been used on OpenVMS, I gather the elapsed time would have been much worse. From looking at the current structure of the UNIX SAMBA code, it looks like the way to improve performance is to write VFS modules specific to ODS-2 and ODS5. The ODS5 module would not need any filename mangling. For the record, we use ODS-2, and switching to ODS-5 would be a major ordeal, as we have all of our clients to consider, not just our own systems. In that module, when a open +write access is done to create a new file, the VFS would delay actually opening the file until either the first data is actualy written, or the client (as per usual observed practice), sends down the actual size of the file. Not being very familiar with SMB or the Samba implementation of it, I'm not sure what specific implications that has for the tests I've been performing. What do I look for in my packet capture logs to see the actual size of the file being communicated by the client to the server? Does that correspond to the 1-byte writes? And if that's the case, how does the server know that write is any different from the actual data write of 1024 bytes? More buffering may also help. The VFS approach may allow more efficient application cache management and tuning. I'll leave that up to you expert filesystem guys to look into. But really, what I'm after for now is anything that might help *without* coding changes, if that is at all possible. Thanks for all of your help so far. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: RE : Packet analysis: WinXP vs. Linux-VMS shows dramatic differ ences
On Wed, 2004-09-22 at 15:59 +0200, COLLOT Jean-Yves wrote:
Another way
to say is: according to me, the WinXP vs. Linux-VMS shows dramatic
differences topic is true only when using ruby. Could someone tell me if
I am right or wrong here?
We ported the ruby script to C++. I'm in the process of running tests,
capturing output, and analyzing it as I did before. Expect results
soon ...
What I can tell you so far is only that the C++ test runs fine on Linux
- OpenVMS with performance figures similar to the Ruby test.
See samba_test.cpp below:
Ben
-- cut here --
#include cerrno
#include cstdlib
#include fstream
#include iostream
#include string
#include ctime
using namespace std;
int main(int argc, char * argv[]) {
time_t startTime, endTime;
char drive[50];
long int blocks = 1, blocksize = 1024;
switch (argc) {
case 1:
strcpy(drive, S:\\);
break;
case 2:
strcpy(drive, argv[1]);
break;
case 3:
strcpy(drive, argv[1]);
blocks = strtol(argv[2], NULL, 10);
if (errno == ERANGE) {
cout Invalid # of blocks: argv[2] endl;
cout Default of 1 used. endl;
blocks = 1;
}
break;
case 4:
strcpy(drive, argv[1]);
blocks = strtol(argv[2], NULL, 10);
if (errno == ERANGE) {
cout Invalid blocks # used: argv[2] endl;
cout Default of 1 used. endl;
blocks = 1;
}
blocksize = strtol(argv[3], NULL, 10);
if (errno == ERANGE) {
cout Invalid blocksize # used: argv[2] endl;
cout Default of 1024 used. endl;
blocksize = 1024;
}
break;
default:
cout Usage: samba_test.exe {drive {blocks {blocksize}}} endl;
}
cout Generating stats with the following arguments: endl;
cout Drive: drive endl;
cout Blocks: blocks endl;
cout Blocksize: blocksize endl;
char * data;
data = new char[blocksize];
memset(data, ' ', blocksize);
char dataFile[60];
strcpy(dataFile, drive);
strcat(dataFile, BENCH.TMP);
ofstream fout;
time(startTime);
fout.open(dataFile);
if (fout.bad()) {
cout Error opening the data file endl;
}
for (int i=0; i blocks; i++) {
fout data endl;
}
fout.close();
remove(dataFile);
time(endTime);
long int elapsed_time = (long) difftime(endTime, startTime),
bytesOut = blocks * blocksize;
cout On drive drive time to write bytesOut
bytes = elapsed_time seconds. endl;
delete [] data;
return 0;
}
-- cut here --
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug report (12=17020 TC029) SAMBA 2.2.8 release 20040908 -
On Wed, 2004-09-22 at 10:13 -0500, John E. Malmberg wrote: In article [EMAIL PROTECTED], RR - Rod Regier [EMAIL PROTECTED] writes: - TC029 Where are these tracking numbers coming from? They do not look like SAMBA Bugzilla numbers. Internal only. Rolling out Samba at Dymaxion has been a long and costly adventure, necessitating the tagging of our time spent on each issue with a separate number. To date, we have spent at least 325 hours working on Samba. Is this problem reproducable with a UNIX SAMBA implementation of 2.2.8 or later? If it is, I haven't tried. Is there a SAMBA Bugzilla entry for this? Not that I know of. Not that anyone is actively looking at SAMBA bugzilla reports for VMS. Nor would I expect them to. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
WinXP - OpenVMS tests reproduced using C++ test program
I have reproduced the same test results as for the ruby test program,
only this time using a C++ port of it. I saw the same samba protocol
pattern of a 1024-byte write followed by one 1-byte write after the
first 64K observed in the packet capture log, and similar performance
numbers. Please ignore the earlier version I posted, as it was buggy,
and use the one below instead. This should work on OpenVMS, Linux and
Windows.
This should settle the question over what's this ruby thing now. :)
As before, I have a packet capture log if anyone wants to see it.
-- cut here --
#include errno.h
#include stdlib.h
#include fstream
#include iostream
#include string.h
#include time.h
using namespace std;
int main(int argc, char * argv[]) {
time_t startTime, endTime;
char drive[50];
long int blocks = 1, blocksize = 1024;
switch (argc) {
case 1:
strcpy(drive, S:\\);
break;
case 2:
strcpy(drive, argv[1]);
break;
case 3:
strcpy(drive, argv[1]);
blocks = strtol(argv[2], NULL, 10);
if (errno == ERANGE) {
cout Invalid # of blocks: argv[2] endl;
cout Default of 1 used. endl;
blocks = 1;
}
break;
case 4:
strcpy(drive, argv[1]);
blocks = strtol(argv[2], NULL, 10);
if (errno == ERANGE) {
cout Invalid blocks # used: argv[2] endl;
cout Default of 1 used. endl;
blocks = 1;
}
blocksize = strtol(argv[3], NULL, 10);
if (errno == ERANGE) {
cout Invalid blocksize # used: argv[2] endl;
cout Default of 1024 used. endl;
blocksize = 1024;
}
break;
default:
cout Usage: samba_test.exe {drive {blocks {blocksize}}} endl;
}
cout Generating stats with the following arguments: endl;
cout Drive: drive endl;
cout Blocks: blocks endl;
cout Blocksize: blocksize endl;
char * data;
data = new char[blocksize+1];
memset(data, ' ', blocksize+1);
data[blocksize] = '\0';
char dataFile[60];
strcpy(dataFile, drive);
strcat(dataFile, BENCH.TMP);
ofstream fout;
time(startTime);
fout.open(dataFile);
if (fout.bad()) {
cout Error opening the data file endl;
}
for (int i=0; i blocks; i++) {
fout data;
}
fout.close();
remove(dataFile);
time(endTime);
long int elapsed_time = (long) difftime(endTime, startTime),
bytesOut = blocks * blocksize;
cout On drive drive time to write bytesOut
bytes = elapsed_time seconds. endl;
delete [] data;
return 0;
}
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
Re: WinXP-Linux samba server test results
On Mon, 2004-09-20 at 18:32 -0400, John E. Malmberg wrote: What version of SAMBA is running on the LINUX system? Samba 3.0.7 + smbfs 3.0.7. Other than that, I am not set up to take advantage of your data at the moment. I do not have any way of reading the etherreal data. If it is because you don't have a Linux system, the ethereal data is not specific to ethereal or Linux. A number of utilities can read it, some of which run on OpenVMS, and many of which run on Windows. Tcpdump, which is available for TCPIP 5.4, can read it. For example: $ tcpdump==$sys$system:tcpip$tcpdump $ tcpdump -vr test.cap Also, tcptrace, which, like tcpdump, is based on libpcap, can read it. See: http://jarok.cs.ohiou.edu/software/tcptrace/download.html e.g. $ tcptrace == $path_to:tcptrace $ tcptrace -v test.cap Finally, if you run Windows, Ethereal works on Windows as well as Linux. It may be useful if you can find a specific difference in the protocol negotiation if the SAMBA versions are the same. Making the Samba versions the same would be a rather costly project for me at this time. I'd like to explore other avenues before trying that. I find it rather interesting that Linux can negotiate Write AndX to write large buffers at a time to OpenVMS, and Windows can negotiate Write AndX to write large buffers at a time to Linux, but Windows can only negotiate Write to write 1K blocks at a time to OpenVMS. So clearly OpenVMS Samba *is* capable of doing Write AndX, since it happily receives them from the Linux client, which writes 4096 byte buffers at a time. Doesn't this indicate that the Samba server, either due to tuning or some other factor, has missed an opportunity to take advantage of a more efficient method of transfer, rather than simply an incompatibility between versions? Also, if pre-allocation is an expensive operation in OpenVMS, doesn't that indicate there is room for improvement here in the current Samba implementation for OpenVMS? Since the Windows host insists on preallocating, and since OpenVMS Samba refuses (or is unable) to send back EOF and allocation responses to the file info requests, it appears that Windows thinks it can only pre-allocate a small amount ahead of where it is writing, instead of further ahead, as it does in the Windows - Linux case. Wouldn't sending back EOF and allocation figures allow the Windows client to write further ahead, resulting in fewer preallocation requests? As it stands, after the first 64K are written, one file info + one extra preallocation write are done per 1024 byte block written! That is exorbitantly expensive, and totally unnecessary, if only the server would give the client the info necessary to make larger, and therefore fewer preallocation writes. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE: WinXP-Linux samba server test results
Hi, I received this private reply, but there is nothing particularly private about these recommendations. I think it is useful information to be discussing on the list, so I have stricken the respondent's name in the interests of privacy, and quoted it in its entirety. On Mon, 2004-09-20 at 16:55 -0400, Someone wrote: Assuming that you are familiar with VMS the following might be of some help: I have some familiarity, being a user software developer on the platform ever since our first VAX 11/750, and am working closely with my OpenVMS sys admin, who has been a sys admin for many OpenVMS systems over roughly the same time period, and therefore is much better versed in tuning than I am. File extends are very expensive operations on OpenVMS. Have you investigated your RMS defaults and insured that high water marking is turned off? I asked my sys admin. It is turned off. I have not done a lot of performance testing (the performance being a big issue with us), but do know that such can kill the performance. We have benchmarked sequential file operations on VMS and the PC. The Windows platform performs such much faster, but is making far fewer in process writes to the disk. Basically, the on disk image in VMS is much closer to that in memory than the PC's. High water marking really slows things down since when blocks are allocated, the allocation operation does not finish until all of the blocks allocated have been zero'ed according to the established security policy. OK. That isn't a factor here, then. A large initial file size value, e.g. 2048 blocks (1MB) and a large extend value of 2048 (1MB) blocks will help since these are also expensive operations. That's why I think OpenVMS Samba ought to be doing a better job sending back EOF/allocation info, so the Windows client can look ahead further instead of the tiny increments it is using now. Depending on the code with-in SAMBA, multi-buffering might help as well as some of the other features such as write behind. I can't comment on that. Would someone more familiar with the Samba code please answer this point? The VMS disks should also be packed so that the files can be allocated in contiguous pieces. Various of the ACP caching parameters will yield some incremental performance gains. We have scheduled defragmentation running most nights. Slightly elevated execution priorities, large default set and working set sizes, etc. will also yield incremental gains in performance. We are looking for order of magnitude increases. I know a number of incremental gains might help a little bit, but I suspect there is something more fundamentally wrong here, given the discrepancy in test times I am seeing between the platforms. By my sysop's judgement, we have done a fair job so far ensuring the underlying filesystem is optimized that the OS environment (working set, etc.) is properly tuned. Check to see if the SAMBA processes ever end up in any of the miscellaneous wait states. These could be caused by insufficient resources. VMS is very sensitive to proper system tuning. I'll add that to the things we are watching. Thanks. I have noticed that SMBD seems to be constrained by DIO. Test times increase proportionally with decreases in available DIO to the SMBD processes. This is not exactly an earth-shaking revelation. We believe that we have our systems well tuned for most I/O intensive applications. SAMBA performance is acceptable when dealing with small numbers of small files but degrades as the file sizes and numbers increase. Overall the performance of SAMBA 2.2.8 is an order of magnitude better than earlier versions on OpenVMS. Be that as it may, it still falls short by an order of magnitude when compared to Linux client - OpenVMS server. So it appears the Samba server, even with our current filesystem and OS tuning measures in place, is capable of much better performance than we are seeing. Hence my present line of inquiry regarding the differences in protocol negotiation. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Packet analysis: WinXP vs. Linux-VMS shows dramatic differences
Hi, I'm trying to figure out why the bench.rb test program I included in my previous note takes several times longer to run using a WinXP client than a Linux client, both talking to our OpenVMS samba server. The big picture question is, How do we tune our clients and/or server to improve overall performance? I have captured packets between a WinXP client the OpenVMS Samba server and also between a Linux client the OpenVMS Samba server while running bench.rb. The quick summary of my analysis of the capture files is that vastly more packets (and different kinds) are exchanged between WinXP and OpenVMS than between Linux and OpenVMS. This accounts for the huge difference in performance we are seeing. Given this analysis, can anyone see what's going wrong with the WinXP - OpenVMS Samba conversations, and more importantly, can it be fixed? Details follow. Hardhats required. WinXP-OpenVMS -- For WinXP writing to OpenVMS, after the initial handshaking, the conversation consists largely of SMBwrite requests replies for the first 140 packets, each of which contains 1024 bytes of blanks (ASCII 0x20). There are a couple of netbios-ssn ACKs in there sent from the server back to the client, one at 18615 bytes (window = 61440), the next at 53047. After this point, the conversation changes. The last SMBwrite for 1024 bytes, offset 64512 is followed by a SMBwrite for 1 byte (containing a null) at offset 66559 (which is beyond 64512+1024, contrary to my expectations). This is followed by a SMBTrans2 QUERY_FILE_INFO Query File Standard Info (258) against the FID we are writing to. The response from the server returns without errors, but doesn't seem to contain much. According to ethereal, the SMB data returned by the server is: Allocation Size: 0 End Of File: 0 Link Count: 1 Delete Pending: Normal, no pending delete (0) Is Directory: This is NOT a directory (0) Unknown Data: Every write that follows is now broken into two writes, one containing the 1024 bytes of blanks, (resuming at offset 65536, where I'd expect the next byte to be written,) and one containing a single null, (the next one at 67583, again beyond the end of data,) and after that, another QUERY_FILE_INFO (each immediately followed by a response from the server). The conversation continues like that: - write + response (1024 bytes) - write + response (1 byte) - file info + response The only other packets, appearing at irregular but infrequent intervals, are netbios-ssn ACK packets (the next at 75305, 95926, 101991, 106927, etc.) going from the server back to the client. In the end, 29890 packets are sent by the client, and 30648 are received. The whole ordeal takes 4 minutes 3 seconds elapsed time, for a staggeringly slow send throughput of 49851 Bps (on a 100 Mbps network!) Linux - OpenVMS By contrast, the Linux to OpenVMS conversation is much more straightforward. A total of 7535 packets are sent and 5116 packets are received, taking 27 seconds elapsed time, for a send throughput of 387309 Bps, an order of magnitude better than WinXP. After the initial handshaking, the Linux client sends SMBWriteX (note, *not* SMBWrite) requests to VMS, each one for 4096 bytes, which don't all fit, given an MTU of 1500, so they are broken into 1392 for the first packet, which contains the extra header stuff, 1460 for the next continuation packet, and finally 1244 in the final continuation packet, for a total of 4096. Each SMBWriteX of 4096 bytes is followed by a netbios-ssn ACK (to ack the 4096 byte reassembly, I guess,) and a SMBWriteX response ACK back from the server. The conversation continues this way until the end of file. The big question is, given the above analysis, can anyone see what's going wrong with the WinXP - OpenVMS Samba conversations, and more importantly, can it be fixed? Thanks, Ben p.s. I will supplement this test with a WinXP client - Linux Samba server test to see which of the two conversations it more closely resembles, and will email the results of that test under separate cover. p.p.s. The raw libpcap capture files are available upon request if anyone wants to do a deeper analysis of my data. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
WinXP-Linux samba server test results
Hi, Here is an analysis of my next test, supplemental to my earlier observations about WinXP - OpenVMS samba write performance. If you want to skip the details and cut to the chase, it seems that both when WinXP talks to a Linux samba server and when Linux talks to a OpenVMS server, efficiencies of the SMB protocol are being taken advantage of that are missing in the WinXP to OpenVMS server conversation. I am supplying my further analysis below in case it helps resolve this mystery, and particularly in case it helps us tune our server and/or clients to perform optimally. Details below. Hardhats required. In this test, I ran bench.rb on WinXP against a Linux samba server. I see a slightly different pattern happening here that bears some similarity to both the Linux client - OpenVMS server case and the WinXP client - OpenVMS server case. As in the Linux - OpenVMS server case, Write AndX is used instead of Write. But similar to the WinXP - OpenVMS server case, I am seeing these one-byte writes. Only this time, surprisingly, they make sense to me. These writes appear to be intended to pre-extend the file up to however much the WinXP client has buffered up and is prepared to write. Furthermore, the QUERY_FILE_INFO requests are getting actual allocation and EOF figures back. Initially, there is a flurry of these which finally settle down once the file has been preextended to 1057791 bytes, after which the first Write AndX happens. This is the second surprise: these writes are sent 64K at a time, unlike the prior two tests. I guess this corresponds to the send buffer size. These are of course chopped up into 1460 byte packets to fit MTU = 1500. As before, there are netbios-ssn ACKs along the way, and after each 64K sent, a Write AndX ACK is sent back from the Linux server. Finally, the writes catch up with the pre-extended size of the file, and another flurry of extensions happen. The session continues alternating between extending and writing in this fashion until the whole data stream is written. I can't compare throughput. While our test Samba OpenVMS server has a 10 MBit interface, my test Samba Linux server has 100 MBit. I could force my Linux server down to 10 MBit half duplex to match the OpenVMS server with mii-tool if that would help. Please let me know if further tests are needed to isolate the differences we are seeing between platforms. As before, I have raw packet capture data for analysis if anyone wants to look at it. Thanks, Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Windows-VMS Samba performance issue
On Fri, 2004-09-17 at 14:04 -0500, John E. Malmberg wrote: Or were you looking for Windows client tuning tips? Well, since the Linux client performance against the VMS Samba shares is considered within an acceptable range of responsiveness relative to performance against our Windows XP shares, that would suggest that server tuning is of less importance than client tuning. The only possible exception is where the server might be tuned in such a way that discriminates heavily against Windows client accesses. I will address your other points in another note. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Windows-VMS Samba performance issue
OK, now for the server end of things: A weekend upgrade is scheduled, so here are current and after-upgrade versions: On Fri, 2004-09-17 at 14:04 -0500, John E. Malmberg wrote: VMS version? OpenVMS 7.3-1 (upgrade will bring this up to 7.3-1 on Monday). TCPIP platform and version? TCPIP V5.3 ECO 4 (upgrade will bring this up to V5.4 ECO 2 on Monday) Samba version? 2.2.8-20040908 (no change on Monday) There is one key difference in how some Microsoft Windows clients treat large files and how SAMBA does. SAMBA sends the file sequentially from start to finish. For some unknown reason, Microsoft Windows sends the first part of the file, skips a bit and sends the middle, and then backfills. Our benchmark routine would prevent that sort of copying, wouldn't it? It simply writes a stream of blocks sequentially. And it just may be a case where SAMBA to SAMBA transfers are more efficient than WINDOWS to SAMBA transfers, since you would expect that if it were really a server issue, that the server would perform badly for both clients. A factor of 10X more efficient? I'm as inclined as the next Linux- hugging geek to glibly say well, Windows sucks, what do you expect? but that's a pretty huge discrepancy! That's what leads me to believe it is simply a matter of things not being tuned optimally for Windows to Samba communication, and yes, probably at the client end, but I don't believe we can rule out the server out of hand. If you use a LINUX SAMBA server instead of a VMS SAMBA server, do you see the same difference in performance? When I use a Linux Samba server, the numbers for the Windows client are as follows: C: (Local) ~0 sec H: (WinXP) ~2 sec G: (Linux Samba) ~15 sec S: (OpenVMS Samba) ~76 sec And considering that the Linux Samba server is my own workstation, which is only a PII/400 with an old 4G ATA-33 drive, not a server-class system, I can certainly understand the slower performance than the WinXP server. But the OpenVMS Samba server figure is way out there. I can't compare performance here with a networked Linux client, because my workstation is the sole Linux system here. The socket options for the Linux server are: socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=4096 The socket options for the VMS server are the defaults. I don't know how to examine those. The conf file doesn't list any. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
VFC File truncated when copied from VMS to Linux via smbfs
I have a pair of log files of similar size and format that always are truncated somewhere at around the 16000'th out of 19000+ lines when I copy them from a Samba 2.2.8 VMS system to a Linux system running Samba 3.0.4 and smbfs (Linux 2.6.7). A dir/full of one of the files is as follows: SYNEDT_P.BG;1 File ID: (259952,18,0) Size: 1950/2001 Owner:[DV,BG] Created:20-JUL-2004 13:33:36.00 Revised:20-JUL-2004 13:33:36.00 (7) Expires:20-JUL-2014 13:50:42.06 Backup: No backup recorded Effective: None specified Recording: None specified Accessed: None specified Attributes: None specified Modified: None specified Linkcount: 1 File organization: Sequential Shelved state: Online Caching attribute: Writethrough File attributes:Allocation: 2001, Extend: 0, Global buffer count: 0 Version limit: 1 Record format: VFC, 2 byte header, maximum 0 bytes, longest 3828 bytes Record attributes: Print file carriage control RMS attributes: None Journaling enabled: None File protection:System:RWED, Owner:RWED, Group:RWED, World: Access Cntrl List: None Client attributes: None If I convert the file using this stream.fdl and then copy the file, it is no longer truncated by the copy: FILE ORGANIZATIONsequential RECORD BLOCK_SPAN yes CARRIAGE_CONTROLcarriage_return FORMAT stream_lf I cannot reproduce the truncation when I copy the file from the VMS system to a Win2K system. Nor can I reproduce the truncation when I use GNOME nautilus to copy the file. Any idea what might be going wrong, here? Ben -- Ben Armstrong-. Medianet Development Group, [EMAIL PROTECTED] `-.Dymaxion Research Limited URL: http://www.dymaxion.ca/`- Halifax, Nova Scotia, Canada PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE: Linux smbfs and smbclient 3.0.0 and 2.2.3a timeout on contact
On Tue, 2003-10-21 at 06:41, Jan-Erik Söderholm XA (TN/PAC) wrote: That wasn't interesting as such, it was the number of direct I/O's to perform the search that was. The issue is that the file is filed up with *deleted* RMS records... I am aware of that. Unfortunately, in my case, the search is simply optimized away since the search thinks there are no records. I end up with only 1 DIO consumed: search samba_root:[var.locks]unexpected.tdb garbagein/log/stat %SEARCH-I-NULLFILE, file SAMBA_ROOT:[VAR.LOCKS]UNEXPECTED.TDB;1 contains no reco rds %SEARCH-S-NOMATCH, SAMBA_ROOT:[VAR.LOCKS]UNEXPECTED.TDB;1 - 0 records Files searched: 1 Buffered I/O count: 6 Records searched: 0 Direct I/O count: 1 Characters searched:0 Page faults: 23 Records matched:0 Elapsed CPU time: 0 00:00:00.00 Lines printed: 0 Elapsed time: 0 00:00:00.00 %SEARCH-I-NOMATCHES, no strings matched Ben -- Ben Armstrong-. Medianet Development Group, [EMAIL PROTECTED] `-.Dymaxion Research Limited URL: http://www.dymaxion.ca/`- Halifax, Nova Scotia, Canada PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Linux smbfs and smbclient 3.0.0 and 2.2.3a timeout on contact
On Mon, 2003-10-06 at 09:14, Ben Armstrong wrote: After upgrading the Alpha/VMS server to 2.2.8 (29-Sep-03 version) my Linux smbfs mount (and even passwordless smbclient -L //servername) now no longer works. Both commands always time out on the connection attempt It seems less and less likely that the particular version of client is at fault. We are seeing the same results with Windows clients. It used to be I could at least intermittently get mounts to work within a couple of seconds. Today, I found I was unable to mount from the Alpha/VMS samba server at all, no matter how many times I retried. I was forced to find a workaround. I obtained the samba source for Linux, changed all timeouts of 2 (two files: source/libsmb/clientgen.c and source/libsmb/libsmbclient.c) to 5 and recompiled. With my smb clients patched in this way I can now successfully mount from the server 100% of the time, with timings similar to these: bgpc:/home/ben# time ./bin/mountdyma real0m33.364s user0m0.330s sys 0m0.010s bgpc:/home/ben# umount /s bgpc:/home/ben# time ./bin/mountdyma real0m33.343s user0m0.320s sys 0m0.020s bgpc:/home/ben# umount /s bgpc:/home/ben# time ./bin/mountdyma real0m33.346s user0m0.330s sys 0m0.020s Is there anything we can do (e.g. turn on debugging either in the server or client, etc.) to further explore what is taking the mounts so long? Thanks, Ben Armstrong -- Ben Armstrong-. Medianet Development Group, [EMAIL PROTECTED] `-.Dymaxion Research Limited URL: http://www.dymaxion.ca/`- Halifax, Nova Scotia, Canada PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Linux smbfs and smbclient 3.0.0 and 2.2.3a timeout on contact
Hi, After upgrading the Alpha/VMS server to 2.2.8 (29-Sep-03 version) my Linux smbfs mount (and even passwordless smbclient -L //servername) now no longer works. Both commands always time out on the connection attempt: bgpc:/home/ben# smbclient -L //dyma Password: session setup failed: Call timed out: server did not respond after 2 milliseconds bgpc:/home/ben# smbclient --version Version 3.0.0-Debian Since I'm using a point-oh release, I thought I'd try downgrading from 3.0.0 (final release, Debian sid/unstable) to 2.2.3a. After the downgrade I still could not connect. Any idea what I should be looking for to troubleshoot this problem? So far as I know, none of the Windows clients are having trouble connecting after the upgrade. Thanks, Ben Armstrong -- Ben Armstrong-. Medianet Development Group, [EMAIL PROTECTED] `-.Dymaxion Research Limited URL: http://www.dymaxion.ca/`- Halifax, Nova Scotia, Canada PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: smbfs reads Variable files incorrectly from VMS Samba 2.2.8
On Fri, 2003-03-28 at 18:25, Gorazd Kikelj wrote: Did you try seting SYSGEN parameter RMS_HEURISTIC to 1? On pathworks this can make a difference when interpreting text files. I did check this parameter and it is 0 on our system. But having my sys admin change SYSGEN parameters is definitely outside of my comfort zone. Is there any evidence this would make a difference for Samba/VMS? Also, given that an adequate explanation has already been given for why this is expected behaviour with smbfs + Samba/VMS 2.2.8, I have my doubts that it would help. Ben -- Ben Armstrong-. Medianet Development Group, [EMAIL PROTECTED] `-.Dymaxion Research Limited URL: http://www.dymaxion.ca/`- Halifax, Nova Scotia, Canada PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Re[2]: smbfs reads Variable files incorrectly from VMS Samba
On Mon, 2003-03-31 at 14:57, [EMAIL PROTECTED] wrote: RMS_HEURISTIC controls whether RMS analyzes selected sequential files to determine if they are normal text or binary files. If RMS_HEURISTIC is enabled (with a value of 1), RMS analyzes sequential files with both a record format (RFM) of STM and a longest-record-length (LRL) of 0 when the files are initially opened. By default in OpenVMS Version 7.1, the heuristic is disabled systemwide. It affects only those files that would normally be of interest only to a connecting Unix system. All that will be added is a little bit of overhead. At the worst, the sysadmin can simply reset it to zero. It's certainly work the brief trial, considering it's a dynamic parameter. That doesn't sound like it would be of any help for my failing test case, which involves a Variable file with LRL = 4. Even such a small, low-risk change would not be worth bothering my sys admin to try unless it seemed likely that it would help. But I'll keep it in mind if more promising alternatives don't turn up. Thanks, Ben -- Ben Armstrong-. Medianet Development Group, [EMAIL PROTECTED] `-.Dymaxion Research Limited URL: http://www.dymaxion.ca/`- Halifax, Nova Scotia, Canada PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Mounting samba 2.2.7a from Linux read-write hazardous
On Tue, 2003-03-25 at 11:17, Ben Armstrong wrote: I will be first downgrading smbfs to see if this is only a bug in my bleeding-edge version on not. Any other suggestions would be appreciated. I have downgraded my smbfs to a much earlier, stable release: 2.2.3a and can still reproduce the file type munging bug with that version. This would seem to make it less likely that smbfs is the source of the bug (although again it doesn't entirely rule out the possibility). Ben -- Ben Armstrong-. Medianet Development Group, [EMAIL PROTECTED] `-.Dymaxion Research Limited URL: http://www.dymaxion.ca/`- Halifax, Nova Scotia, Canada PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
