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=-2.2 required=3.0 tests=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 2E1A7C433E0 for ; Wed, 17 Jun 2020 11:31:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 107C720CC7 for ; Wed, 17 Jun 2020 11:31:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726538AbgFQLbV (ORCPT ); Wed, 17 Jun 2020 07:31:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:46750 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725901AbgFQLbU (ORCPT ); Wed, 17 Jun 2020 07:31:20 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 04337AEC8; Wed, 17 Jun 2020 11:31:22 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 8A8A9DA7C3; Wed, 17 Jun 2020 13:31:09 +0200 (CEST) Date: Wed, 17 Jun 2020 13:31:09 +0200 From: David Sterba To: Qu Wenruo Cc: Josef Bacik , Qu Wenruo , linux-btrfs@vger.kernel.org Subject: Re: [PATCH 2/4] btrfs: detect uninitialized btrfs_root::anon_dev for user visible subvolumes Message-ID: <20200617113109.GK27795@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Qu Wenruo , Josef Bacik , Qu Wenruo , linux-btrfs@vger.kernel.org References: <20200616021737.44617-1-wqu@suse.com> <20200616021737.44617-3-wqu@suse.com> <0e274dc7-ac05-078a-2a2c-348e72745d45@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0e274dc7-ac05-078a-2a2c-348e72745d45@suse.com> 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, Jun 17, 2020 at 07:49:33AM +0800, Qu Wenruo wrote: > >>> Can we handle stat->dev not having a device set?  Or will this blow up > >>> in other ways?  Thanks, > >> > >> We can handle it without any problem, just users get confused. > >> > >> As a common practice, we use different bdev as a namespace for different > >> subvolumes. > >> Without a valid bdev, some user space tools may not be able to > >> distinguish inodes in different subvolumes. > >> > > > > Alright that's fine then.  But I feel like stat is one of those things > > that'll flood the console, can we put this somewhere else that's going > > to be hit less? Thanks, > > Unfortunately, stat() is the only user of btrfs_root::anon_dev. > > While fortunately, the logical is pretty simple, even without the safe > net we can understand the lifespan pretty well. > > I'm fine to drop this patch if you're concerned about the possible > warning flood, as the benefit is really not that much. It could be a developer-only warning but if there's a root with a bad anon_dev, a simple 'ls -l' would flood the log for sure.