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.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 CA635C43461 for ; Thu, 15 Apr 2021 18:18:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFA3460249 for ; Thu, 15 Apr 2021 18:18:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234447AbhDOSSb (ORCPT ); Thu, 15 Apr 2021 14:18:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233923AbhDOSS1 (ORCPT ); Thu, 15 Apr 2021 14:18:27 -0400 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89BDDC061574 for ; Thu, 15 Apr 2021 11:18:02 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id s5so17436799qkj.5 for ; Thu, 15 Apr 2021 11:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FboUBx+M7wiC2Vc9ohnMu1xFLntMIR1IX9IeLkEPHjI=; b=B03mrf5IAbFUf4B8lNYRNg/BJbtQSZsQEhMlkF6ndvHEbOuxkenRmydetxWF7gzpTT 7MzBb6QgYldj531EgGVSDSQd9RbXexAh6ZHvjRDAl1NRm1h5hegzEDhHs0jhhuApYQH7 IU+E0i23QU0wmN4wVKSSca4bg5UiAN/V4aiTxZYShFGltfRKGGKhJJg/0ul3dd4kIgxo mlHcMDQ5EbzfpLv3IgD4GIjWXNU/TFZc+xUSiocQPBIs9Sy+f6oMvzUF2moGCU5obTD+ qZGpYJV6qGdDRdNM3Hetv6PABFnZCYNhNEOepzKhn7agw+tDxs8lglyebVISVoy2k/1v Q3aA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FboUBx+M7wiC2Vc9ohnMu1xFLntMIR1IX9IeLkEPHjI=; b=Om7TnwQ9KtWK5fDnnIFp+na1rjjbBIhQWDeyLaVwNnO2GConpwGRKnxRTlrMijkYLw J9ajLbGxl+elj2E1X1nlTV6fWTHwjM39Y9ZDC+gQ1zGGpNVhILqdQG4Q7vSsLwZMtlFk b3gFRlhokmgEdZ667tPLoAbHpQ9XakNoEHUTdHPgbW6zhoQXL+5bT4FPpruA2upQbl0z F6g6miWD7x5ik2QIxxclUgt1yOoVnVnJ5Vg1ZLURNN4hts88nRFYQHO+JE3CTZz5virN YOWjOQP0rYFW7qeWcpmmYsRxDrtVaJdnosLC7vm6cuybzZhipnqR8Rl0xEItWyTN3v3n d04Q== X-Gm-Message-State: AOAM533Z0k3XWSfX8oHo3pCO5N283AX+hu38zDqpNmCNqjHyU+ojZyZI QhSq3D+RHtLhxvTEEDdaf0G6+Q== X-Google-Smtp-Source: ABdhPJzwmJZmG/p+pl3buOTcZzktD3WLTreTOFcX4K4JsmD+TrNZ3sJfvua3mjs+PVPFIecVlojLpA== X-Received: by 2002:ae9:d61c:: with SMTP id r28mr4721507qkk.462.1618510681561; Thu, 15 Apr 2021 11:18:01 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a8:11c9::1288? ([2620:10d:c091:480::1:2677]) by smtp.gmail.com with ESMTPSA id d62sm2569722qkg.55.2021.04.15.11.18.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Apr 2021 11:18:00 -0700 (PDT) Subject: Re: [RFC v3 0/2] vfs / btrfs: add support for ustat() To: Luis Chamberlain , Filipe Manana , David Sterba Cc: Al Viro , Chris Mason , Josef Bacik , Christoph Hellwig , Linux FS Devel , Btrfs BTRFS , "linux-kernel@vger.kernel.org" , Jeff Mahoney References: <1408071538-14354-1-git-send-email-mcgrof@do-not-panic.com> <20140815092950.GZ18016@ZenIV.linux.org.uk> From: Josef Bacik Message-ID: Date: Thu, 15 Apr 2021 14:17:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/15/21 1:53 PM, Luis Chamberlain wrote: > On Wed, Aug 23, 2017 at 3:31 PM Jeff Mahoney wrote: >> >> On 8/15/14 5:29 AM, Al Viro wrote: >>> On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote: >>> >>>> Christoph had noted that this seemed associated to the problem >>>> that the btrfs uses different assignments for st_dev than s_dev, >>>> but much as I'd like to see that changed based on discussions so >>>> far its unclear if this is going to be possible unless strong >>>> commitment is reached. >> >> Resurrecting a dead thread since we've been carrying this patch anyway >> since then. >> >>> Explain, please. Whose commitment and commitment to what, exactly? >>> Having different ->st_dev values for different files on the same >>> fs is a bloody bad idea; why does btrfs do that at all? If nothing else, >>> it breaks the usual "are those two files on the same fs?" tests... >> >> It's because btrfs snapshots would have inode number collisions. >> Changing the inode numbers for snapshots would negate a big benefit of >> btrfs snapshots: the quick creation and lightweight on-disk >> representation due to metadata sharing. >> >> The thing is that ustat() used to work. Your commit 0ee5dc676a5f8 >> (btrfs: kill magical embedded struct superblock) had a regression: >> Since it replaced the superblock with a simple dev_t, it rendered the >> device no longer discoverable by user_get_super. We need a list_head to >> attach for searching. >> >> There's an argument that this is hacky. It's valid. The only other >> feedback I've heard is to use a real superblock for subvolumes to do >> this instead. That doesn't work either, due to things like freeze/thaw >> and inode writeback. Ultimately, what we need is a single file system >> with multiple namespaces. Years ago we just needed different inode >> namespaces, but as people have started adopting btrfs for containers, we >> need more than that. I've heard requests for per-subvolume security >> contexts. I'd imagine user namespaces are on someone's wish list. A >> working df can be done with ->d_automount, but the way btrfs handles >> having a "canonical" subvolume location has always been a way to avoid >> directory loops. I'd like to just automount subvolumes everywhere >> they're referenced. One solution, for which I have no code yet, is to >> have something like a superblock-light that we can hang things like a >> security context, a user namespace, and an anonymous dev. Most file >> systems would have just one. Btrfs would have one per subvolume. >> >> That's a big project with a bunch of discussion. > > 4 years have gone by and this patch is still being carried around for > btrfs. Other than resolving this ustat() issue for btrfs are there new > reasons to support this effort done to be done properly? Are there > other filesystems that would benefit? I'd like to get an idea of the > stakeholder here before considering taking this on or not. > Not really sure why this needs to be addressed, we have statfs(), and what we have has worked forever now. There's a lot of larger things that need to be addressed in general to support the volume approach inside file systems that is going to require a lot of work inside of VFS. If you feel like tackling that work and then wiring up btrfs by all means have at it, but I'm not seeing a urgent need to address this. Thanks, Josef