From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91DF0C433E2 for ; Mon, 31 Aug 2020 13:23:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6C9D720782 for ; Mon, 31 Aug 2020 13:23:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726292AbgHaNXq (ORCPT ); Mon, 31 Aug 2020 09:23:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:44012 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726144AbgHaNXp (ORCPT ); Mon, 31 Aug 2020 09:23:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D1CE0B64A; Mon, 31 Aug 2020 13:04:56 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 136C6DA840; Mon, 31 Aug 2020 15:03:45 +0200 (CEST) Date: Mon, 31 Aug 2020 15:03:44 +0200 From: David Sterba To: Urs Thuermann Cc: linux-btrfs@vger.kernel.org Subject: Re: Link count for directories Message-ID: <20200831130344.GW28318@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Urs Thuermann , linux-btrfs@vger.kernel.org References: <20200824222306.GA26736@angband.pl> <5062163c-47ff-f811-7b37-e74e1ef47265@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, Aug 26, 2020 at 09:04:21AM +0200, Urs Thuermann wrote: > > Find certainly paid attention, but from an optimization point of > > view, dtype in directory entries is dramatically more helpful. > > 1. dtype is not in POSIX. It is not but is this a problem in practice? Linux supports d_type and that's what matters right now (manual page says that some BSDs support that too). > OTOH, I seem to remember that POSIX states > st_link == 1 for directories or otherwise it has the traditional > value of 2 + sub-directory count. However, I cannot find this > anymore. Is that correct and can anyone give me a pointer? I can't find a reliable source for that but I remember reading it somewhere. > 2. If you just want to find all directories you only need stat(2) on a > directory and if it has st_nlink == 2 you don't need to read all > directory entries (with or without dtype). So this optimization is > possible with the traditional link count of directories but not > with dtype. > > > I'd want to see big wins from applications before adding this > > into btrfs. > > I would expect noticable but not big wins. The usecasee you describe skips readdir in case there are no directories, ie. if there are, full readdir will need to be done anyway. I can see that this saves some calls but otherwise it's IMHO quite narrow. > However, I'd like adding > this to btrfs just because it looks nicer. Since ls (and readdir) > gives you the . and .. links they should be counted in the usual way. As said elsewhere, this comes with a cost of backward compatibility issues and unfortunatelly overrides a 'nice to have' feature.