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.1content-type=text/x-cvsweb-markup http://www.openbsd.org/cgi-bin/cvsweb/ports/net/samba/patches/patch-lib_replace_repdir_getdirentries_c?rev=1.1content-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
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.1content-type=text/x-cvsweb-markup http://www.openbsd.org/cgi-bin/cvsweb/ports/net/samba/patches/patch-lib_replace_repdir_getdirentries_c?rev=1.1content-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 (19) 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
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
