Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933014AbbENMq4 (ORCPT ); Thu, 14 May 2015 08:46:56 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49132 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932420AbbENMqy (ORCPT ); Thu, 14 May 2015 08:46:54 -0400 Date: Thu, 14 May 2015 14:46:49 +0200 From: Jan Kara To: Dave Chinner Cc: Linus Torvalds , Al Viro , Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig , Neil Brown Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks Message-ID: <20150514124649.GD10093@quack.suse.cz> References: <20150505052205.GS889@ZenIV.linux.org.uk> <20150511180650.GA4147@ZenIV.linux.org.uk> <20150513222533.GA24192@ZenIV.linux.org.uk> <20150514033040.GF7232@ZenIV.linux.org.uk> <20150514112304.GT15721@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150514112304.GT15721@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1905 Lines: 37 On Thu 14-05-15 21:23:04, Dave Chinner wrote: > On Wed, May 13, 2015 at 08:52:59PM -0700, Linus Torvalds wrote: > > And readdir() itself, for that matter - we have no good vfs-level > > readdir caching, so it all ends up serialized on the inode > > semaphore, and it all goes all the way into the filesystem to get > > the readdir data. And at least for ext4, readdir() > > is slow anyway, because it doesn't use the page cache, it uses > > that good old buffer cache, because of how ext4 does metadata > > journaling etc. > > IIRC, ext4 readdir is not slow because of the use of the buffer > cache, it's slow because of the way it hashes dirents across blocks > on disk. i.e. it has locality issues, not a caching problem. For ext4 readdir is just a linear read of the directory. Linus is right we store directory blocks in buffer cache but we do our own readahead on directory blocks so I don't think much slowness comes from that. One thing that is slowing us down is that we don't do preallocation for directories so they often end up being fragmented a lot. The locality problem you are probably referring to is that readdir on ext4 returns directory entries in hash order. That is different from the ordering by inode number which is optimal for the following cache-cold stat / unlink / whatever you want to do with inodes. This causes big performance issues e.g. if you do rm -rf on large directory hierarchy. But you don't see that often these days as lots of utilities have learned to workaround ext4 problems by sorting directory entries by inode number before doing anything with them. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/