From owner-freebsd-questions@FreeBSD.ORG Tue Feb 28 02:21:50 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E4D5106564A for ; Tue, 28 Feb 2012 02:21:50 +0000 (UTC) (envelope-from rbanfield@weogeo.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D91C8FC14 for ; Tue, 28 Feb 2012 02:21:50 +0000 (UTC) Received: by pbcwy7 with SMTP id wy7so538019pbc.13 for ; Mon, 27 Feb 2012 18:21:50 -0800 (PST) Received-SPF: pass (google.com: domain of rbanfield@weogeo.com designates 10.68.225.129 as permitted sender) client-ip=10.68.225.129; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rbanfield@weogeo.com designates 10.68.225.129 as permitted sender) smtp.mail=rbanfield@weogeo.com Received: from mr.google.com ([10.68.225.129]) by 10.68.225.129 with SMTP id rk1mr2061926pbc.51.1330395710119 (num_hops = 1); Mon, 27 Feb 2012 18:21:50 -0800 (PST) Received: by 10.68.225.129 with SMTP id rk1mr1692049pbc.51.1330395709982; Mon, 27 Feb 2012 18:21:49 -0800 (PST) Received: from [192.168.0.2] (pool-72-91-240-41.tampfl.fios.verizon.net. [72.91.240.41]) by mx.google.com with ESMTPS id f9sm14259170pbq.60.2012.02.27.18.21.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Feb 2012 18:21:49 -0800 (PST) Message-ID: <4F4C3A3A.9080903@weogeo.com> Date: Mon, 27 Feb 2012 21:21:46 -0500 From: Robert Banfield User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <4F4BFB09.9090002@weogeo.com> <4F4C094C.1010900@infracaninophile.co.uk> In-Reply-To: <4F4C094C.1010900@infracaninophile.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnENfBsD2ARZEwvB47HIRp0YTR6G9JPIMMN4d+JeMEpd+46xHdL4dZWB6BZVINf6gtxg9vW Subject: Re: "find" not traversing all directories on a single zfs file system X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 02:21:50 -0000 On 02/27/2012 05:53 PM, Matthew Seaman wrote: > > These are all actual directories -- no symbolic link or anything like > that? I assume permissions are not the problem? All directories have > at least mode r_x for your user id? (Hmmm... but you are logged in as > root -- can't be that then.) How about ACLs? Are you using those at > all on your filesystem? There are no symbolic links, nor any ACLs at all anywhere on the system. All the directories have rwx for root, and permissions are not a problem. > The symptoms you are observing are definitely incorrect, and not at all > what the vast majority of find(1) users would experience. Something is > definitely a bit fubar on your machine. It would be useful to try and > establish if it is the find(1) program giving bogus results, or whether > it is some other part of the system. Do other methods of printing out > the filesystem contents suffer from the same problem -- eg. 'ls -R .' or > 'tar -cvf /dev/null .' ls -R appears to be traversing all subdirectories. > Is there anything in the system log or printed > on the console? (Note: I always find it useful to enable the > console.log and all.log by uncommenting the relevant lines in > /etc/syslog.conf and following the other instructions there.) da0 runs the operating system. da1-12 are set up as a RAIDZ2 with 2 hot spares. # zpool status pool: tank0 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM tank0 ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 label/zfsdisk1 ONLINE 0 0 0 label/zfsdisk2 ONLINE 0 0 0 label/zfsdisk3 ONLINE 0 0 0 label/zfsdisk4 ONLINE 0 0 0 label/zfsdisk5 ONLINE 0 0 0 label/zfsdisk6 ONLINE 0 0 0 label/zfsdisk7 ONLINE 0 0 0 label/zfsdisk8 ONLINE 0 0 0 label/zfsdisk9 ONLINE 0 0 0 label/zfsdisk10 ONLINE 0 0 0 spares label/zfsdisk11 AVAIL label/zfsdisk12 AVAIL # glabel status Name Status Components gptid/d49367f4-5cfc-11e1-be4b-000423b4b110 N/A da0p1 label/zfsdisk1 N/A da1 label/zfsdisk2 N/A da2 label/zfsdisk3 N/A da3 label/zfsdisk4 N/A da4 label/zfsdisk5 N/A da5 label/zfsdisk6 N/A da6 label/zfsdisk7 N/A da7 label/zfsdisk8 N/A da8 label/zfsdisk9 N/A da9 label/zfsdisk10 N/A da10 label/zfsdisk11 N/A da11 label/zfsdisk12 N/A da12 These messages appear in the output of dmesg: GEOM: da1: the primary GPT table is corrupt or invalid. GEOM: da1: using the secondary instead -- recovery strongly advised. (repeat for da2 - da12) GEOM: da1: corrupt or invalid GPT detected. GEOM: da1: GPT rejected -- may not be recoverable. GEOM: da1: corrupt or invalid GPT detected. GEOM: da1: GPT rejected -- may not be recoverable. (repeat for da2-da12) GEOM: label/zfsdisk1: corrupt or invalid GPT detected. GEOM: label/zfsdisk1: GPT rejected -- may not be recoverable. Could this be related, or a separate issue? > Also, is this 9.0-RELEASE straight from the installation media, or did > you compile it yourself? If you compiled it yourself, what compiler did > you use (gcc or clang)? What optimization and what architecture > settings -- trying to tweak such things for maximum optimization > frequently leads to dissapointment. This is straight from the 64-bit memstick install. I have used both the standard install /usr/bin/find as well as a compiled /usr/src/usr.bin/find/ and both give the same results. I have no tweaks for zfs other than to zfs_enable on boot. Because this machine has 16GB of RAM, I believe prefetch is automatically enabled. I have some additional information that I didnt see before actually digging into the log file. It is quite interesting. There are 82,206 subdirectories in one of the folders. Like this: /zfs_mount/directoryA/token[1-82206]/various_tileset_files When looking at the output of find, here is what I see: Lines 1-9996943: The output of find, good as good can be Lines 9996944-10062479: Subdirectory entries only, it traversed none of them. Notice 10062479-9996944+1 = 65536 = 2^16 So, of the 82206 subdirectories, the first 82206-2^16 were traversed, and the final 2^16 were not. The plot thickens...