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> In-Reply-To: <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk> References: <20161021120536.GI57876@zxy.spb.ru> <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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`
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161021130758.GJ57876>