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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 CD63EC4320E for ; Fri, 30 Jul 2021 15:17:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B228260F46 for ; Fri, 30 Jul 2021 15:17:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238909AbhG3PRz (ORCPT ); Fri, 30 Jul 2021 11:17:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239509AbhG3PRy (ORCPT ); Fri, 30 Jul 2021 11:17:54 -0400 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E14A5C061765; Fri, 30 Jul 2021 08:17:49 -0700 (PDT) Received: by fieldses.org (Postfix, from userid 2815) id 765D96C0C; Fri, 30 Jul 2021 11:17:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 765D96C0C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1627658268; bh=Li85SDlcyV77joGjmGDEsUglXDaV5Llbu6EqziOjsyk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hmBdBXPsolGx/6yQJRZFOCw1ozPtQ3p9NLGLQPVTKL8SGFMkIiiHLmQxDrTMcR/w8 Cm5TAbqvKfh6Kc94qsr0O54PvbB3Vrn38d7tI2h+LumarzcT8OqZEsyTRoo6lDG75L Uz8vZbrwqRkgMQKewqArRRbp5TnloKzSZhbYvyKk= Date: Fri, 30 Jul 2021 11:17:48 -0400 From: "J. Bruce Fields" To: Qu Wenruo Cc: NeilBrown , Zygo Blaxell , Neal Gompa , Wang Yugui , Christoph Hellwig , Josef Bacik , Chuck Lever , Chris Mason , David Sterba , Alexander Viro , linux-fsdevel , linux-nfs@vger.kernel.org, Btrfs BTRFS Subject: Re: [PATCH/RFC 00/11] expose btrfs subvols in mount table correctly Message-ID: <20210730151748.GA21825@fieldses.org> References: <162745567084.21659.16797059962461187633@noble.neil.brown.name> <162751265073.21659.11050133384025400064@noble.neil.brown.name> <20210729023751.GL10170@hungrycats.org> <162752976632.21659.9573422052804077340@noble.neil.brown.name> <20210729232017.GE10106@hungrycats.org> <162761259105.21659.4838403432058511846@noble.neil.brown.name> <341403c0-a7a7-f6c8-5ef6-2d966b1907a8@gmx.com> <162762468711.21659.161298577376336564@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Fri, Jul 30, 2021 at 02:23:44PM +0800, Qu Wenruo wrote: > OK, forgot it's an opt-in feature, then it's less an impact. > > But it can still sometimes be problematic. > > E.g. if the user want to put some git code into one subvolume, while > export another subvolume through NFS. > > Then the user has to opt-in, affecting the git subvolume to lose the > ability to determine subvolume boundary, right? Totally naive question: is it be possible to treat different subvolumes differently, and give the user some choice at subvolume creation time how this new boundary should behave? It seems like there are some conflicting priorities that can only be resolved by someone who knows the intended use case. --b.