Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
On Mon, Apr 28, 2008 at 09:05:29PM +0100, Edd Barrett wrote: > 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: > > [global] > workgroup = MYGROUP > server string = Samba Server > security = share > log file = /var/log/smbd.%m > directory name cache size = 0 > > [public] >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. Did you remove the lib/replace/repdir_getdirentries.c code as well ? The aborts will still trigger even with "directory name cache size = 0" if that code is in place. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
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 : > > https://bugzilla.samba.org/show_bug.cgi?id=4715 > > 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 > > lib/replace/repdir_getdirentries.c > > entirely. > > 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. > > Jeremy. 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: [global] workgroup = MYGROUP server string = Samba Server security = share log file = /var/log/smbd.%m directory name cache size = 0 [public] 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. -- Best Regards Edd http://students.dec.bmth.ac.uk/ebarrett -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
Jeremy Allison schrieb: 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 Thank you very much for your explanations. I must admit that I am quite shocked about this. I always thought of Samba as one of the most important products that can be run on a Unix machine. It would be quite sad for the *BSDs if nobody takes care of this. Well, maybe that troll on slashdot is right... :( bye, Uwe -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
On Tue, Apr 29, 2008 at 10:06:18AM +0100, Edd Barrett wrote: > Hi, > > On Fri, Apr 25, 2008 at 3:00 PM, Edd Barrett <[EMAIL PROTECTED]> wrote: > > I am willing to test patches. I may have a prod about in the source at > > some point, but you guys can probably diagnose and fix the fault a > > whole load better than I can. I have never looked at the samba source > > before. > > 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 : https://bugzilla.samba.org/show_bug.cgi?id=4715 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 lib/replace/repdir_getdirentries.c entirely. 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. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
Hi, On Fri, Apr 25, 2008 at 3:00 PM, Edd Barrett <[EMAIL PROTECTED]> wrote: > I am willing to test patches. I may have a prod about in the source at > some point, but you guys can probably diagnose and fix the fault a > whole load better than I can. I have never looked at the samba source > before. 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 -- Best Regards Edd http://students.dec.bournemouth.ac.uk/ebarrett -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
Hi again, On Fri, Apr 25, 2008 at 10:34 AM, Volker Lendecke <[EMAIL PROTECTED]> wrote: > Without that debug log it's kindof hard to say. Here is one :) [2008/04/25 16:44:09, 8] smbd/dosmode.c:dos_mode(371) dos_mode: ./RMshaders [2008/04/25 16:44:09, 8] smbd/dosmode.c:dos_mode_from_sbuf(188) dos_mode_from_sbuf returning d [2008/04/25 16:44:09, 8] smbd/dosmode.c:dos_mode(409) dos_mode returning d [2008/04/25 16:44:09, 5] smbd/trans2.c:get_lanman2_dir_entry(1255) get_lanman2_dir_entry found ./RMshaders fname=RMshaders [2008/04/25 16:44:09, 10] smbd/trans2.c:get_lanman2_dir_entry(1398) get_lanman2_dir_entry: SMB_FIND_FILE_BOTH_DIRECTORY_INFO [2008/04/25 16:44:09, 10] smbd/mangle_hash2.c:name_map(617) name_map: RMshaders -> 0F710AE4 -> R4A8P2~C (cache=1) [2008/04/25 16:44:09, 8] smbd/trans2.c:get_lanman2_dir_entry(1161) get_lanman2_dir_entry:readdir on dirptr 0x85f1d300 now at offset 132 [2008/04/25 16:44:09, 8] smbd/dosmode.c:dos_mode(371) dos_mode: ./Games [2008/04/25 16:44:09, 8] smbd/dosmode.c:dos_mode_from_sbuf(188) dos_mode_from_sbuf returning d [2008/04/25 16:44:09, 8] smbd/dosmode.c:dos_mode(409) dos_mode returning d [2008/04/25 16:44:09, 5] smbd/trans2.c:get_lanman2_dir_entry(1255) get_lanman2_dir_entry found ./Games fname=Games [2008/04/25 16:44:09, 10] smbd/trans2.c:get_lanman2_dir_entry(1398) get_lanman2_dir_entry: SMB_FIND_FILE_BOTH_DIRECTORY_INFO [2008/04/25 16:44:09, 0] lib/fault.c:fault_report(41) === [2008/04/25 16:44:09, 0] lib/fault.c:fault_report(42) INTERNAL ERROR: Signal 6 in pid 3156 (3.0.28a) Please read the Trouble-Shooting section of the Samba3-HOWTO [2008/04/25 16:44:09, 0] lib/fault.c:fault_report(44) From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf [2008/04/25 16:44:09, 0] lib/fault.c:fault_report(45) === [2008/04/25 16:44:09, 0] lib/util.c:smb_panic(1633) PANIC (pid 3156): internal error [2008/04/25 16:44:09, 0] lib/util.c:log_stack_trace(1787) unable to produce a stack trace on this platform [2008/04/25 16:44:09, 3] smbd/sec_ctx.c:push_sec_ctx(208) push_sec_ctx(1000, 1000) : sec_ctx_stack_ndx = 1 [2008/04/25 16:44:09, 3] smbd/uid.c:push_conn_ctx(358) push_conn_ctx(101) : conn_ctx_stack_ndx = 0 [2008/04/25 16:44:09, 3] smbd/sec_ctx.c:set_sec_ctx(241) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2008/04/25 16:44:09, 5] auth/auth_util.c:debug_nt_user_token(448) NT user token: (NULL) [2008/04/25 16:44:09, 5] auth/auth_util.c:debug_unix_user_token(474) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2008/04/25 16:44:09, 0] lib/fault.c:dump_core(181) dumping core in /opt/var/cores/smbd I am willing to test patches. I may have a prod about in the source at some point, but you guys can probably diagnose and fix the fault a whole load better than I can. I have never looked at the samba source before. -- Best Regards Edd http://students.dec.bournemouth.ac.uk/ebarrett -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
Edd schrieb: Before I file a bug report, I just wanted to check that samba is capable of serving files from a FAT32 partition. I have here an OpenBSD-4.2 This reminds me of https://bugzilla.samba.org/show_bug.cgi?id=4715 Short description: Samba crashes on any filesystem except UFS. You could test wether it is the same problem or not by installing Samba 3.023 or 3.024. If they work with FAT32, it's probably the same Problem that bites us on FreeBSD (and keeps us from using Samba+FreeBSD in production). :-/ bye, Uwe -- Molkerei Ammerland eG Oldenburger Landstraße 1a 26215 Wiefelstede Phone : +49-04458-9111- 23 Fax : +49-04458-9111-980 Email : [EMAIL PROTECTED] Web-Site: http://www.molkerei-ammerland.de eG mit Sitz in Wiefelstede, Registergericht Oldenburg, GnR 120009 Vorstand: Gerd Wemken (Vorsitzender), Herbert Heyen (stellv. Vorsitzender), Hermann Boekhoff, Frank Caspers, Werner Freese, Johann Gieseke, Heiko Hinrichs, Fritz-Harald Strodthoff-Schneider, Heino Suhr, Diedrich Wilken Aufsichtsratsvorsitzender: Justus Ackermann -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba segs when serving files from a windows partition on OpenBSD-4.2
On Fri, Apr 25, 2008 at 10:14:07AM +0100, Edd wrote: > Before I file a bug report, I just wanted to check that samba is capable > of serving files from a FAT32 partition. I have here an OpenBSD-4.2 > i386 machine here with a second disk containting files that I will be > sharing via both NFS and samba. The NFS share work great, but samba seg > faults upon a windows client connecting. This occurs when using the > OpenBSD package, and also when built from scratch using the most recent > version of samba (downloaded yesterday). > > If I change the share path to a directory on a UFS partition, all is > well. > > I can not get a stack trace, as even with symbols enabled, the log tells > me that it cannot make a core dump for this architecure. > > I can however get a "log level = 10" paste later today if needed. > > Is this a bug or a limitation in samba? Without that debug log it's kindof hard to say. Volker pgpcOb32a8IBX.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
