ACCVIO in CIFS on all file access, generates lots of process dump files

[Jeremy Begg]

Hi,

We're currently testing CIFS V1.0 on an HP rx2660 server running OpenVMS V8.3-1H1 and MultiNet V5.2.

I've done a very basic configuration, allowing personal shares and one general-purpose fileshare (see SMB.CONF below). It would appear that enabling automatic record format conversion with the 'vfs objects' statement causes the SMBD server process to fail with an ACCVIO.

The failure seems to happen on *every* attempt to access a file (either putting one to the server or getting one back). Each failure results in an OPCOM message (courtesy of MultiNet) and a process dump file in whatever directory the user was trying to access. This is rapidly causing many MB of disk space to be filled by SAMBA$SMBD.DMP files!

We have most of the current VMS patches installed including VMS831HI_ACRTL V1.0.

Here is the SMB.CONF file:

[global]
server string = Samba %v running on HP Integrity rx2660 (OpenVMS)
netbios name = samba.ilg.com.au
security = user
passdb backend = tdbsam
domain master = yes
guest account = SAMBA$GUEST
domain logons = Yes
log file = /samba$root/var/log_%h.%m
create mode = 0755
load printers = no
printing = OpenVMS

[homes]
comment = Home Directories
browseable = no
read only = no
create mode = 0750
vfs objects = streamlf varvfc

[sandpit]
browsable = yes
writeable = yes
path = /D2/sandpit/
vfs objects = streamlf varvfc


I've checked the SMBD server process records in ACCOUNTNG.DAT and they all fail with the same Peak Page File value -- but this value is a lot less than the SYSUAF PGFLQUOTA value. The running process seems to have the same PGFLQUOTA as specified in SYSUAF, so I don't think it's a quota issue at this stage.

Any suggestions?

Thanks,
Jeremy Begg

[Volker Halle]

Jeremy,

take one of those SAMBA$SMBD.DMP files and raise a call with HP. Alternatively, contact the HP CIFS team via the 'submit feedback' button on the HP CIFS page.

You can also have a look at the dump yourself and at least provide some stack information.

$ ANAL/PROC/IMAGE=samba$root:samba$smbd.exe dev:SAMBA$SMBD.DMP
DBG> EXA/INS @PC
DBG> SHOW CALL
DBG> EXIT

Volker.

[Peter_364]

Have you checked the SYSGEN values of PGFLQUO?
Issue a MC SYSGEN SHOW PQL
It's possible SMBD uses SYSGEN paramters.
If I remember right SMBD had logfiles that produced some usage output that could give you an hint.

Regards, Peter

[Willem Grooters]

[quote]
It would appear that enabling automatic record format conversion with the 'vfs objects' statement causes the SMBD server process to fail with an ACCVIO.
[/quota]
I have some a faint memory that there is something wrong with varVFC files and CIFS. Whether I read it somewhere, or it was told in some session on the subject, I cannot tell. What I do know is that handling these files will take a lot of time, and it was higly recommended NOT to use VFC files on a CIFS share.

[Jeremy Begg]

Thanks for your replies.

I reported this via the CIFS Feedback page at about the same time as I wrote my message here, and got a response to the effect that I should remove "streamlf" from my "vfs objects" option. (The response also said that the feedback page was not to be used for reporting problems, which should be logged via standard support channels.)

Doing so seems to have stopped the ACCVIOs, but leaves me suspicious that Samba can handle only one one record format conversion per share.

I think I'll log an official support case to see if we can get this fixed.

Thanks,
Jeremy Begg

[Jeremy Begg]

I think we may have solved our problem for now.

The ACCVIO is definitely a bug in CIFS which the development team will fix. However it was triggered by inappropriate use of 'vfs objects' options.

The "streamlf" option is intended for use in situations where files created by CIFS clients must have STMLF format when saved to a VMS CIFS server. (The cited example was when the server has a Java application which will be reading those files.) Hence we don't need it.

The "varvfc" option is the one we need as it can (supposedly!) convert sequential files with VAR and STMLF record format to STM format as they are sent to CIFS clients. (The "conversion" is on-the-wire; the actual source files are not modified.)

Removing "streamlf" from our 'vfs objects' statements has ended the ACCVIOs and restored CIFS stability. We still have more testing to do but it's looking a lot more positive now.