[Samba] Samba segs when serving files from a windows partition
vext01 at gmail.com
Mon Apr 28 20:05:29 GMT 2008
On Tue, Apr 29, 2008 at 10:34:22AM -0700, Jeremy Allison wrote:
> On Tue, Apr 29, 2008 at 10:06:18AM +0100, Edd Barrett wrote:
> > It turns out OpenBSD-current has some patches to fix this problem
> > which came from FreeBSD, just after the release of 4.2.
> > Is the samba team interested in taking the patches upstream?
> > http://www.openbsd.org/cgi-bin/cvsweb/ports/net/samba/patches/patch-lib_iconv.c?rev=1.1&content-type=text/x-cvsweb-markup
> > http://www.openbsd.org/cgi-bin/cvsweb/ports/net/samba/patches/patch-lib_replace_repdir_getdirentries_c?rev=1.1&content-type=text/x-cvsweb-markup
> Unfortunately the patch-lib_replace_repdir_getdirentries_c patch
> is completely wrong. It removes the abort assert, but doesn't change
> the code that the abort is trying to assert. That whole replace
> file assumes that an integral number of directory entries always
> fit in a DIR_BUF_SIZE (1<<9) sized buffer. If they don't then
> this code simply doesn't work, which is why the abort is called.
> This file should be removed, when we know that this bug has
> been fixed in the *BSD's.
> " This is needed because the existing directory handling in FreeBSD
> and OpenBSD (and possibly NetBSD) doesn't correctly handle unlink()
> on files in a directory where telldir() has been used. On a block
> boundary it will occasionally miss a file when seekdir() is used to
> return to a position previously recorded with telldir().
> This also fixes a severe performance and memory usage problem with
> telldir() on BSD systems. Each call to telldir() in BSD adds an
> entry to a linked list, and those entries are cleaned up on
> closedir(). This means with a large directory closedir() can take an
> arbitrary amount of time, causing network timeouts as millions of
> telldir() entries are freed"
> Is this now the case ? Last time I requested info in this Terry Lambert @ Apple
> claimed that this behavior (doesn't correctly handle unlink() on files in a
> directory where telldir() has been used. On a block boundary it will
> occasionally miss a file when seekdir() is used to return to a position
> previously recorded with telldir()) was allowed by POSIX and there was no
> intention of fixing it.
> If this is true it puts us at an impasse, as all other POSIX systems
> don't behave like this. I did do some work on our directory handling
> code in smbd/dir.c by adding a parameter "directory name cache size"
> which turns off the performance boost if set to zero. Check out the
> (long) bug report here :
> The last person to check this reported the change did not work
> for him. If this is incorrect, and setting "directory name cache size =
> 0" works for *BSD systems then I can remove the code in
> In addition, has the second bug been fixed in the *BSD's (the :
> "Each call to telldir() in BSD adds an entry to a linked list"
> bug) ?
> If you give me feedback, I will close this out for 3.2. Unfortunately
> it's hard to get anyone on the *BSD side to work on this with me. I
> tend to be demand driven, and if someone from the *BSD community is
> willing to work directly with me to ensure Samba works on *BSD, I'd
> be happy to keep Samba working happily on these platforms. I don't
> have time to do a lot of testing on *BSD myself though, that's the
> problem. Guenther Kukkuk is a great example of how this can work.
> He drive us to keep fixing bigs with the OS/2 client support and
> is now a member of the Samba Team.
I am sure that the OpenBSD team will be interested in fixing these bugs
if they still exist, as they take pride making good quality code. I
can't speak for NetBSD or FreeBSD.
As for the "directory name cache size = 0" it does not work for me. On
OpenBSD. I used this configuration:
workgroup = MYGROUP
server string = Samba Server
security = share
log file = /var/log/smbd.%m
directory name cache size = 0
comment = Public Stuff
path = /mnt/hot/sd0i
public = yes
writable = yes
printable = no
I tested this with samba-latest.tgz from your web-page.
If I change the path to someplace else on a UFS slice, all is well.
Unfortunately I am not really the one to speak to regarding this, but I
will CC in the maintainer of Samba for OpenBSD.
Marc, do you know anything about these potential issues?
Thats not to say I am not willing to help. I will help if I can.
More information about the samba