Samba+xHarbour

[danca]

Hi all,
I recently upgraded two servers running Linux and consequently Samba
suite has been updated too.

Now it seems that there are problems with cdx indexes, they get
corrupted and users report that some operations are much slower (append
from or delete records, still to investigate).

Anybody experienced the same or similar problems?

Dan

[cul...@gmail.com]

Which samba version, did you disable samba oplocks

Regards
Luiz

[danca]

Il 12/01/2015 13:22, cul...@gmail.com ha scritto:
> Which samba version, did you disable samba oplocks
>
> Regards
> Luiz
>

Previous working version was 3.2.5
I never disabled oplocks with Samba in the last 10+ years.
I'll see the version number of the newly installed one.
Thx in between

Dan

[prgwiz]

No problems at all with the 3.6 series of Samba on Ubuntu 12.04.5 for many years. Updating that machine to Ubuntu 14.04.1 and the Samba 4.x version did introduce major issues when there was high load on the databases and force us to downgrade to back to 12.04.5.
You have to disable oplocks on the client and server
Client side you can use something like this...
FUNCTION gg_OS_NETREGOK( lSetIt, lDoVista )
LOCAL rVal:= .T., cKeySrv, cKeyWks,ckeyFile
local aCheck:={},aOut:={},aReg
IF lSetIt == NIL
lSetIt:= .F.
ENDIF
IF lDoVista == NIL
lDoVista:= .T.
ENDIF
IF !lDoVista .AND. OS_ISWINVISTA()
return(aOut)
endif
cKeySrv:="System\CurrentControlSet\Services\LanmanServer\Parameters"
cKeyWks:="System\CurrentControlSet\Services\LanmanWorkStation\Parameters"
cKeyFile:="System\CurrentControlSet\Control\FileSystem"
IF OS_ISWIN9X()
aadd(aCheck,{"System\CurrentControlSet\Services\VxD\VREDIR","DiscardCacheOnOpen",1}) //=hex:01
aadd(aCheck,{cKeyFile,"AsyncFileCommit",1}) //=hex:01
aadd(aCheck,{cKeyFile,"DriveWriteBehind",0}) //=hex:00,00,00,00
aadd(aCheck,{cKeyFile,"SoftCompatMode",0}) //=hex:00,00,00,00
ELSE
// Server settings
aadd(aCheck,{cKeySrv, "CachedOpenLimit", 0})
aadd(aCheck,{cKeySrv, "EnableOpLocks", 0}) // Q124916
aadd(aCheck,{cKeySrv, "EnableOpLockForceClose", 1})
aadd(aCheck,{cKeySrv, "SharingViolationDelay", 0})
aadd(aCheck,{cKeySrv, "SharingViolationRetries", 0})

// Workstation settings
aadd(aCheck,{cKeyWks, "UseOpportunisticLocking", 0})
aadd(aCheck,{cKeyWks, "EnableOpLocks", 0})
aadd(aCheck,{cKeyWks, "EnableOpLockForceClose", 1})
aadd(aCheck,{cKeyWks, "UtilizeNtCaching", 0})


IF OS_ISWIN2000_OR_LATER()
aadd(aCheck,{"System\CurrentControlSet\Services\MRXSmb\Parameters","OpLocksDisabled",1})
aadd(aCheck,{ cKeyWks, "FileInfoCacheLifetime", 0})
aadd(aCheck,{ cKeyWks, "FileNotFoundCacheLifetime", 0})
aadd(aCheck,{ cKeyWks, "DirectoryCacheLifetime", 0})
/* If SMB2 is enabled turning off oplocks does not work, so SMB2 is required to be turned off on Server. */
aadd(aCheck,{ cKeySrv, "SMB2", 0})
ENDIF
ENDIF
aadd(aCheck,{cKeyWks, "UseLockReadUnlock", 0})
for each aReg in aCheck
if lSetIt
rVal :=SetRegistry( 0,aReg[1],aReg[2],aReg[3])
else
rVal :=QueryRegistry( 0,aReg[1],aReg[2],aReg[3])
endif
if !rVal
aadd(aOut,aReg)
endif
next
RETURN( aOut )


Smb.conf
;Make sure /etc/security/limits.conf has the following or you will run out of file handles especially on the telnet server:
;* soft nofile 524288
;* hard nofile 524288

[global]
max open files = 32768
load printers = no
printing=bsd
printcap name=/dev/null
show add printer wizard=no
disable spoolss=yes
wide links =no
# log level = 2
name resolve order = wins bcast hosts
strict locking=no

dns proxy=no

workgroup = YOURWG

security = domain

#For version 4.x this will probably be needed:
#security=user

#for BDC
#domain logons=yes
#domain master=no
#for PDC
#domain logons=yes
#domain master=yes

map to guest = bad user
guest account=nobody

password server = 192.168.0.11
wins server = 192.168.0.11
; passdb backend = tdbsam
;encrypt passwords = Yes
idmap uid = 10000-200000
idmap gid = 10000-200000
winbind separator=+
winbind enum users =yes
winbind enum groups=yes
winbind cache time =15
winbind use default domain=yes
local master =no
domain master=no
template shell=/bin/bash
obey pam restrictions=yes
; smb ports=445
[data]
guest ok=no
; guest only=yes
oplocks = no
writable = yes
public = yes
; force user = root
level2 oplocks = no
printable = no
path = /raid/srv/pubdocs
force group = users
# force group = root
dos filetimes = yes
#11/10/11 gerry: 0660 will not work. eservice writing to the images directory will give 0660 file but is invisible from windows browsers
#0770 will create the file with 0760, seems weird but it works for everything.
#be careful changing the masks as the changes seem to take effect as soon as you save the file. A restart or refresh is not needed
create mask = 0770
# force directory mode = 0770
#6/15/05 needed for telnet users... there seems to be some kind of bug here for samba and group rights with telnet sessions.
force directory mode = 6777
# inherit permissions = yes
#yes can add about 10Mbs to getting a file from the server. netperf still works too it appears. But lets leave it off for now.
use sendfile = no

[danca]

Il 14/01/2015 15:09, prgwiz ha scritto:
> No problems at all with the 3.6 series of Samba on Ubuntu 12.04.5 for many years. Updating that machine to Ubuntu 14.04.1 and the Samba 4.x version did introduce major issues when there was high load on the databases and force us to downgrade to back to 12.04.5.

I had problems time ago upgrading from Slackware 12.2 (Samba 3.2.5) to
Slackware 13.37/64 bit. IIRC it was Samba 3.6.xx. The network went slow,
and sometimes the xHarbour program freezed for 30 seconds or more during
browse. After a lot of tinkering I reverted to 12.2. :-(
I was unsure if it was a Samba issue or a network driver issue. (Anyway
I changed the network card too, to no avail).

Now the upgrade was to Slackware 14.1 that comes with Samba 4.1.0. Then
I discovered that the current stable Samba version is 4.1.15 (just
released) and A LOT of problems have been addressed. I have downloaded
the package but it seems I have to compile it (groan).

For instance on one server I tried to revert only Samba to the 3.2.5 (I
had to copy a couple of libraries and regenerate the tdbsam database)
keeping the kernel and all the remaining of the distro unchanged. More
test to come.

> You have to disable oplocks on the client and server

Well I knew that that stuff about oplocks was for Windows server, not
for Samba. Hmmm... I'll make some testing.

> Client side you can use something like this...

<snip>

Many thanks, I will investigate the settings you suggest, mine are quite
different (and I have no telnet users...).

Dan

[prgwiz]

> Now the upgrade was to Slackware 14.1 that comes with Samba 4.1.0. Then
> I discovered that the current stable Samba version is 4.1.15 (just
> released) and A LOT of problems have been addressed. I have downloaded
> the package but it seems I have to compile it (groan).

After the upgrade did not work out, we actually got an external usb thumb drive and installed the old version of Ubuntu on it. Told the bios to boot from that drive, and mount the server raid directories in the appropriate places. At some point when 4.x samba seems stable we will remove the thumb drive and upgrade again.

> Many thanks, I will investigate the settings you suggest, mine are quite
> different (and I have no telnet users...).

Telnet server has the impact of 15-20 users logging in from the same machine with 150+ file handles each.

[danca]

OK.
Just to report what's happening, i only added this paramenter (per-share):
veto oplock files = /*.dbf/*.DBF/*.cdx/*.CDX/*.fpt/*.FPT/

Tech docs I have found state that a source of problems can be the
simultaneous access from Linux native programs and Windows ones (the
reason is always the locking scheme). That's my situation, so I first
tried this approach. So far, no new problems seem to have occurred.

On the other server, the one I finally downgraded to Samba 3.2.5, what
happened is simply terrible. Some records went regularly cancelled (via
delete and pack) but the corresponding memo fields NOT. So I have a
shift and some memo fields are now still related to a record, but the
record has CHANGED of course after the pack. I'm going crazy to
rearrange things starting from a backup and trying to re-add the records
added since the pack and reshifting the memo to their original position.
Madness.

Let's see...

Dan

[Claudio Voskian]

Daniel

Use copy to ... for !deleted() instead.
You won't go crazy anymore (at least not with "pack").

Regards
---
Claudio Voskian
Buenos Aires - Argentina
+54 911 4435-4789

"danca" escribió en el mensaje de noticias:m9bs21$qnm$1...@dont-email.me...

[danca]

Il 16/01/2015 21:45, Claudio Voskian ha scritto:
> Daniel
>
> Use copy to ... for !deleted() instead.
> You won't go crazy anymore (at least not with "pack").
>
> Regards
> ---
> Claudio Voskian

I have another program (derived form a old one and still including some
very old code) in which I used such a technique (but no memo fields
involved there), but it dates back to Clipper era, since many years I
apparently don't have any problem with pack and memo (I had some hiccups
here and there with indexes). I suppose anyway that when something goes
wrong at a level prior to application level ( network level ) there is
no way to avoid data corruption. But probably you are right, some
operations are safer than other. To begin with, doing a "copy to" opens
the target file in exclusive mode and no sharing-related problems can occur.

Here I had a problem clearly depending from the locking of
records/files. It seems that the .fpt file resulted locked and the pack
operation was not able to update the .fpt file and ended up with the
.dbf file packed, and the .fpt unchanged (silently).

Curious, I had a tour to the sources to discover how PACK is
implemented. In \include\std.ch we see that PACK is translated in
__dbPack(), and in \source\rdd\dbcmd.c __dbPack calls in turn SELF_PACK.

In dbf1.c we have hb_dbfPack, that contains this comment:
*/ This is bad hack but looks that people begins to use it :-( so I'll
add workaround to make it more safe /*

Then there is a check if the data structure (related to the file)
field valResult is an array or not. It seems that someone is storing in
this field an array of 2 elements containing a codeblock and a numeric
value. I miss the whole point then I go on.
Follows the conditional execution of a codeblock for every record
processed (a feature I completely was unaware of) and a final rewriting
of the file header.

It seems that the key is the call to SELF_PACKREC() that writes the next
record in the current (if cancelled).

SELF_PACKREC should read the memo field, too, and write it in the
current record, leaving unchanged the pointers that connect the dbf
record to the position in the .fpt binary file where the text/binary
data are stored, but apparently under some conditions fails.

Memo fields can get corrupted in 2 ways, IME. They can contain NIL, and
that makes them non-editable, but the program doesn't throws errors, or
they can be messy (or -3rd possibility- the pointer in the DBF is
inconsistent) and the program goes straight to the errorsys.

Anybody having a large database with memo fields could then benefit from
a service routine that checks and repairs memo fields.
Here is an example:

<open file>

memoflds:={}
for j:=1 to fcount()
if type(fieldname(j))="M"
aadd(memoflds,{fieldname(j),j})
endif
next j
DO WHILE .NOT. EOF()
// skip deleted (optional)
do while deleted()
SKIP
ENDDO
IF EOF()
EXIT
ENDif
for j=1 to len(memoflds)
lInval:=.f.
oldeb:=errorblock({|e|break()})
begin sequence
TESTO:=HARDCR(fieldget(memoflds[j,2]))
recover
testo=""
linval=.t.
end sequence
errorblock(oldeb)
if .not. linval .and. fieldget(memoflds[j,2]) == nil
lInval=.t.
endif
// error
if lInval
mylog("Memo field invalid!"+" rec. n. "+str(recno()) )
// if set exclusive off
//IF REC_LOCK(3) // from LOCKS.PRG - it simply locks a record
(and retries during 3 seconds, then returns lSuccess)
fieldput(memoflds[j,2], testo)
//UNLOCK
//ENDIF
endif
next j
SKIP
enddo

Mylog() is a simple function that writes to a logfile so i don't think
is needed to attach it.

HTH
Dan

[danca]

Il 16/01/2015 21:25, danca ha scritto:

> Just to report what's happening, i only added this paramenter (per-share):
> veto oplock files = /*.dbf/*.DBF/*.cdx/*.CDX/*.fpt/*.FPT/

Not enough. Errors persist.
I'll try disabling oplocks client-side.

Dan