Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1722872pxj; Wed, 19 May 2021 12:20:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfLV7kFGZ6iwaOhwgDoK9AEEpVFFdDy0XWHV817JRi23uGH4ZOVyo7L/knq59Q+ZFayJ6u X-Received: by 2002:a05:6602:54:: with SMTP id z20mr1129422ioz.48.1621452045587; Wed, 19 May 2021 12:20:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621452045; cv=none; d=google.com; s=arc-20160816; b=vkVkaX2uiye0qtXoamC18ZrYyvV0Y9Sur9t+jfBCGQP9arEhZkloDuUeI5LNNqoMY8 Glnn7zKDuFrS30rajrDvxWjRpHLEGh2/2P41ikNYgy+ca4/FKspQ5nrRDKCIgLTvm9Si 5Tx7N1cLNYiKN8pEuoOVjm4nfJlka+eWZhzaJwqikAkdb/odI4V1QufXtfFKe1YJI7Gw gvDbmUGKixsRLhOjkQON2H2BrFR4+UZNICs67CUg6ZqkOQylCGDv+Ift33PDiThL04gp 7BnQPE6wwneOFPMKvhcaYwFNWxX2GNThlSYEk88NO7avphKb5U2YxSfW6Z2Pr2jGJ7tU UqdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=LQxYHlpQlKzbVy7Qs+DZ8b8cOO6vCYLqnE0OUJbqO1U=; b=n2vBjUPAW6ah9HY94242n3Mh5PwpQ+6fuFITeH4QWdy7Xb6UR6foj5cHFDyVXum2MB ZZaN6cbASBJaaWQupoPFDiKwzhIZcByOH/QvxDUoQmBiiAK4ljn4p2C22ShBGlSybrD3 TP/re6eRhKA4LRPL9Vru2fypTaHpbvUz1xgvJ4/Sbl1MPnOm8bj/7ezrUuAANL8zHfwO E8h//TCV+PwFOoYayNDdTzg3Pm33nDBZYnCEEOqfib4jgKkFGDxY9MvNcqgMMRSKZCaE xt5mSsGwA0DKCOG6x5Cco5gz+5T8/SY0/H7VkNrm4KuRny2fn0Yu51j191h2wt4wQ/Dc AZ+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@scylladb-com.20150623.gappssmtp.com header.s=20150623 header.b="yzeGv/BU"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b12si189087jai.103.2021.05.19.12.20.30; Wed, 19 May 2021 12:20:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@scylladb-com.20150623.gappssmtp.com header.s=20150623 header.b="yzeGv/BU"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240555AbhESIB2 (ORCPT + 99 others); Wed, 19 May 2021 04:01:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236042AbhESIB0 (ORCPT ); Wed, 19 May 2021 04:01:26 -0400 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12258C061763 for ; Wed, 19 May 2021 01:00:07 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id 62so5710414wmb.3 for ; Wed, 19 May 2021 01:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scylladb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=LQxYHlpQlKzbVy7Qs+DZ8b8cOO6vCYLqnE0OUJbqO1U=; b=yzeGv/BUCDTAG4K7Xj6Q59o2Grqt+YdTNA3vK535i9ipWxVppRJnFemU2Dy1tO6K8/ +HzTFy63yLu1tcxorUcLVHwGNLbfEk+H82EDibPbw2XUkGIey3u+oUT409bXFJKuwvbk O2e/ucFwvQ2xRlQGpfPBvt4MgXNf7jEbXb1UffNizZv32Al361n1MNn1O1aXWmD7dDKA G95DPJNuV0cfJpW74NSPaXL7Venkqtp+Fr1GP9dDxe9ka+eQ1srRkcZ0R4tpUM0DQZ6o MnfsUDwsZEe7JMRl1Tp8GcAwU5U/tZo49sbARRHga2J5DrMRY9ir/iURjcDMnZrw88hV GX8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=LQxYHlpQlKzbVy7Qs+DZ8b8cOO6vCYLqnE0OUJbqO1U=; b=JQAbhJ55qybuQDHdxFQOykiPJjHbCUmlfmVfFFqjS2f1pKKyI8H8bx0a88ulYxqimb tr7VojU1qUWQtYh24iHnmsGsbc8p6WqU6NIka/6h8Xo6jE4TDhjw4Esf/oivxxEmieJk 4QWoK13oyiMJqe51ZM11ieLvU22zQY/v2m107OliJIfiOzQ7LXn9OpTlp7SBKmLbx+S/ +QgFhvepYLGElILDJKss3k7S2dNwN62n4vxh3uHZl6u+25Sk15fumdhTqaTs59lEDc4Z ldZcGhTyRpSXWmmqBdpyUGjDVeUCbdTI0sJ9lDC5A2VV6Bp0zJF8W/k/Nt4L+jiYSero l9Uw== X-Gm-Message-State: AOAM533Dnn7T93uaCz4S0igtKRJb1p+1x3cDiXGCB2e7mkfH1rXA43yi Xh6MM4xl7wQC8yrPTQmfSVaVsA== X-Received: by 2002:a1c:df04:: with SMTP id w4mr9976713wmg.158.1621411205505; Wed, 19 May 2021 01:00:05 -0700 (PDT) Received: from avi.scylladb.com (system.cloudius-systems.com. [199.203.229.89]) by smtp.gmail.com with ESMTPSA id m9sm4485432wmq.40.2021.05.19.01.00.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 May 2021 01:00:05 -0700 (PDT) Subject: Re: How capacious and well-indexed are ext4, xfs and btrfs directories? To: Dave Chinner , David Howells Cc: Theodore Ts'o , Andreas Dilger , "Darrick J. Wong" , Chris Mason , linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-cachefs@redhat.com, linux-fsdevel@vger.kernel.org References: <206078.1621264018@warthog.procyon.org.uk> <20210517232237.GE2893@dread.disaster.area> From: Avi Kivity Organization: ScyllaDB Message-ID: Date: Wed, 19 May 2021 11:00:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210517232237.GE2893@dread.disaster.area> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 18/05/2021 02.22, Dave Chinner wrote: > >> What I'd like to do is remove the fanout directories, so that for each logical >> "volume"[*] I have a single directory with all the files in it. But that >> means sticking massive amounts of entries into a single directory and hoping >> it (a) isn't too slow and (b) doesn't hit the capacity limit. > Note that if you use a single directory, you are effectively single > threading modifications to your file index. You still need to use > fanout directories if you want concurrency during modification for > the cachefiles index, but that's a different design criteria > compared to directory capacity and modification/lookup scalability. Something that hit us with single-large-directory and XFS is that XFS will allocate all files in a directory using the same allocation group. If your entire filesystem is just for that one directory, then that allocation group will be contended. We saw spurious ENOSPC when that happened, though that may have related to bad O_DIRECT management by us. We ended up creating files in a temporary directory and moving them to the main directory, since for us the directory layout was mandated by compatibility concerns. We are now happy with XFS large-directory management, but are nowhere close to a million files.