From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 05:02:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 303CD16A468 for ; Fri, 6 Jul 2007 05:02:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2A713C46E for ; Fri, 6 Jul 2007 05:02:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 05 Jul 2007 22:02:13 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 138F6125ADD for ; Thu, 5 Jul 2007 22:02:13 -0700 (PDT) Message-ID: <468DCCE1.2020404@elischer.org> Date: Thu, 05 Jul 2007 22:02:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: FreeBSD Current Content-Type: multipart/mixed; boundary="------------040108090204020407060904" Cc: Subject: [Fwd: Re: [Fwd: Re: ZFS vs Samba Debugging Results ... Need Help.]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2007 05:02:14 -0000 This is a multi-part message in MIME format. --------------040108090204020407060904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarded from Jeremy of the samba group. --------------040108090204020407060904 Content-Type: message/rfc822; name="Re: [Fwd: Re: ZFS vs Samba Debugging Results ... Need Help.].eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [Fwd: Re: ZFS vs Samba Debugging Results ... Need Help.]"; filename*1=".eml" Return-Path: X-Original-To: julian@elischer.org Delivered-To: julian@idiom.com Received: from lists.samba.org (mail.samba.org [66.70.73.150]) by idiom.com (Postfix) with ESMTP id 8E99C125ADB for ; Thu, 5 Jul 2007 19:13:59 -0700 (PDT) Received: by lists.samba.org (Postfix, from userid 549) id E94E7162AE0; Fri, 6 Jul 2007 02:13:57 +0000 (GMT) Date: Thu, 5 Jul 2007 19:13:55 -0700 From: Jeremy Allison To: Julian Elischer Cc: Jeremy Allison Subject: Re: [Fwd: Re: ZFS vs Samba Debugging Results ... Need Help.] Message-ID: <20070706021355.GB5056@samba1> Reply-To: Jeremy Allison References: <468DA1DC.7030809@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <468DA1DC.7030809@elischer.org> User-Agent: Mutt/1.5.11 X-Bogosity: Ham, tests=bogofilter, spamicity=0.236843, version=1.1.5 X-Spam-Status: No, hits=-2.6 required=5 tests=SPF_HELO_PASS,SPF_PASS, BAYES_00 X-ClamAV-Status: No X-Idiom-Reporting: If this was spam, please report it to http://www.spamcop.net On Thu, Jul 05, 2007 at 06:58:52PM -0700, Julian Elischer wrote: > For your ammusement. > > samba blew up when on ZFS due to an unexpected result in some returned > value somewhere.. > (details on demand) I know about this. It's a bug in *BSD. The reason tridge wrote this is here : >From : lib/replace/repdir_getdents.c in Samba. ------------------------------------------------------------------------ /* a replacement for opendir/readdir/telldir/seekdir/closedir for BSD systems 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 Note! This replacement code is not portable. It relies on getdents() always leaving the file descriptor at a seek offset that is a multiple of DIR_BUF_SIZE. If the code detects that this doesn't happen then it will abort(). It also does not handle directories with offsets larger than can be stored in a long, ------------------------------------------------------------------------ Fix your OS please. Jeremy. --------------040108090204020407060904--