From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 02:50:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 546C5D2A; Sat, 25 Apr 2015 02:50:52 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 260DC12F3; Sat, 25 Apr 2015 02:50:52 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3P2okNC029591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 19:50:49 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553B0100.4070307@freebsd.org> Date: Sat, 25 Apr 2015 10:50:40 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jilles Tjoelker , John Baldwin CC: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> <553A7DB0.8080308@freebsd.org> <553A8D28.7090901@freebsd.org> <4718551.Y2ZnMk6NSM@ralph.baldwin.cx> <20150424215249.GA96554@stack.nl> In-Reply-To: <20150424215249.GA96554@stack.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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: Sat, 25 Apr 2015 02:50:52 -0000 On 4/25/15 5:52 AM, Jilles Tjoelker wrote: > On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: >> Yes, this isn't at all safe. There's no guarantee whatsoever that >> the offset on the directory fd that isn't something returned by >> getdirentries has any meaning. In particular, the size of the >> directory entry in a random filesystem might be a different size >> than the structure returned by getdirentries (since it converts >> things into a FS-independent format). >> This might work for UFS by accident, but this is probably why ZFS >> doesn't work. >> However, this might be properly fixed by the thing that ino64 is >> doing where each directory entry returned by getdirentries gives >> you a seek offset that you _can_ directly seek to (as opposed to >> seeking to the start of the block and then walking forward N >> entries until you get an inter-block entry that is the same). > The ino64 branch only reserves space for d_off and does not use it in > any way. This is appropriate since actually using d_off is a major > feature addition. > > A proper d_off would still be useful even if UFS's readdir keeps masking > off the offset so a directory read always starts at the beginning of a > 512-byte directory block, since this allows more distinct offset values > than safely using getdirentries()'s *basep. With d_off, one outer loop > must read at least one directory block to avoid spinning indefinitely, > while using getdirentries()'s *basep requires reading the whole > getdirentries() buffer. > > Some Linux filesystems go further and provide a unique d_off for each > entry. > > Another idea would be to store the last d_ino instead of dd_loc into the > struct ddloc. On seekdir(), this would seek to loc_seek as before and > skip entries until that d_ino is found, or to the start of the buffer if > not found (and possibly return some entries again that should not be > returned, but Samba copes with that). yes.. though maybe a hash of hte inode number and the name may be a better thing to search on.. I need to check on your statement about samba to see if its true for 3.6.. >