linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: kreijack@inwind.it, linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.com>, Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH] btrfs: Create sysfs entries only for non-stale devices
Date: Thu, 16 Dec 2021 00:02:28 +0200	[thread overview]
Message-ID: <86e0c499-da7a-2e3a-1782-502d9b1ef944@suse.com> (raw)
In-Reply-To: <b08f828e-6336-fc09-521a-d4cf439e45d8@libero.it>



On 15.12.21 г. 20:55, Goffredo Baroncelli wrote:
> Hi Nikolay,
> 
> On 12/15/21 15:46, Nikolay Borisov wrote:
>> Currently /sys/fs/btrfs/<uuid>/devinfo/<devid> entry is always created
>> for a device present in btrfs_fs_devices on the other hand
>> /sys/fs/btrfs/<uuid>/devices/<devname> sysfs link is created only when
>> the given btrfs_device::bdisk member is populated. This can lead to
>> cases where a filesystem consisting of 2 device, one of which is stale
>> ends up having 2 entries under /sys/fs/btrfs/<uuid>/devinfo/<devid>
>> but only one under /sys/fs/btrfs/<uuid>/devices/<devname>.
> 
> What happened in case of a degraded mode ? Is correct to not show a
> missing devices ?

Good question, now I'm thinking if 'devices' show the currently
available devices to the filesystem, whilst 'devinfo' is supposed to
show what devices the fs knows about. So in the case of degraded mount
it should really have 2 devices under devinfo and only 1 under device.
But this also means the case you reported shouldn't be handled by the
devinfo sysfs code but rather the admin should do 'btrfs device scan -u'
to remove the stale device.


I'd say this is all pretty open to interpretation so I'd like to also
see David's and Josef's opinions on this.


> 
> 
<snip>

  reply	other threads:[~2021-12-15 22:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15 14:46 [PATCH] btrfs: Create sysfs entries only for non-stale devices Nikolay Borisov
2021-12-15 14:47 ` Nikolay Borisov
2021-12-15 18:55 ` Goffredo Baroncelli
2021-12-15 22:02   ` Nikolay Borisov [this message]
2021-12-16 18:52     ` Goffredo Baroncelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86e0c499-da7a-2e3a-1782-502d9b1ef944@suse.com \
    --to=nborisov@suse.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).