From owner-freebsd-stable@freebsd.org  Fri Oct 21 13:08:04 2016
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFA83C1AF8E
 for <freebsd-stable@mailman.ysv.freebsd.org>;
 Fri, 21 Oct 2016 13:08:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id A30B98DA
 for <freebsd-stable@freebsd.org>; Fri, 21 Oct 2016 13:08:04 +0000 (UTC)
 (envelope-from slw@zxy.spb.ru)
Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD))
 (envelope-from <slw@zxy.spb.ru>)
 id 1bxZYE-000EG8-KA; Fri, 21 Oct 2016 16:07:58 +0300
Date: Fri, 21 Oct 2016 16:07:58 +0300
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: Pete French <petefrench@ingresso.co.uk>
Cc: emz@norma.perm.ru, freebsd-stable@freebsd.org
Subject: Re: zfs, a directory that used to hold lot of files and listing pause
Message-ID: <20161021130758.GJ57876@zxy.spb.ru>
References: <20161021120536.GI57876@zxy.spb.ru>
 <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: slw@zxy.spb.ru
X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>, 
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2016 13:08:05 -0000

On Fri, Oct 21, 2016 at 01:47:08PM +0100, Pete French wrote:

> > In bad case metadata of every file will be placed in random place of disk.
> > ls need access to metadata of every file before start of output listing.
> 
> Umm, are we not talkong abut an issue where the directoyr no longer contains
> any files. It used to have lots, now it has none.
> 
> > I.e. in bad case you will be need tens of thousands seeks over disk
> > capable only 72 seeks per seconds.
> 
> Why does it need to seek all over the disc if there are no files (and hence
> no metadata surely) ?
> 
> I am not bothered if a hufge directoyr takes a while to list,
> thats something I am happy to deal with. What I dont like is
> when it is back down to zero that it still takes a long time
> to list. That doesnt make much sense.

OK, this case may be differ.
May be zdb can help.
ls -li /parent/dir
Take inode number
zdb -vvvv zfs_set inode_number

also do ktrace ls and anaylyse `kdump -E`