From: Marc MERLIN <marc@merlins.org>
To: Anand Jain <anand.jain@oracle.com>
Cc: Nikolay Borisov <nborisov@suse.com>,
dsterba@suse.com, linux-btrfs@vger.kernel.org,
kernel-team@fb.com
Subject: Re: 5.4.20: cannot mount device that blipped off the bus: duplicate device fsid:devid for
Date: Wed, 25 Mar 2020 18:30:07 -0700 [thread overview]
Message-ID: <20200326013007.GS15123@merlins.org> (raw)
In-Reply-To: <a9dd1b1a-b38e-a0f4-91e1-b89063e8ae1e@oracle.com>
On Thu, Mar 26, 2020 at 07:56:10AM +0800, Anand Jain wrote:
> > Are users really supposed to know this?
> > Why does btrfs device scan not invalidate the cache of devices and keep
> > remembering a device that's gone (not visible in new scan)?
>
> btrfs device scan --forget is only useful to cleanup the unmounted
> devices, per the logs below the device was mounted when it disappeared.
> More below.
I'm confused: why is --forget even needed? Why would it remember devices
that were unmounted and not part of a new scan?
And yes, the device was not unmounted. The sata layer failed, device
disappeared while mounted and then re-appeared
I was able to force umount the mountpoints, so maybe --forget would have
helped, but I'm confused as to why it even exists.
> This indicates the device was mounted when it disappeared. So it
> re-appears with the new path, but as its fsid+uuid+devid matches
> with the old still mounted device we rightly consider it as an
> alien device and fail the mount.
It was unmounted after disappearing, see the 'grep sde /proc/mounts'
showing that it wasn't mounted anymore, so it seems that even that part
didn't work as intended?
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Home page: http://marc.merlins.org/
next prev parent reply other threads:[~2020-03-26 1:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-21 20:23 5.4.20: cannot mount device that blipped off the bus: duplicate device fsid:devid for Marc MERLIN
2020-03-21 21:25 ` Nikolay Borisov
2020-03-25 20:14 ` Marc MERLIN
2020-03-25 23:56 ` Anand Jain
2020-03-26 1:30 ` Marc MERLIN [this message]
2020-03-26 3:33 ` Anand Jain
2020-03-26 4:26 ` Marc MERLIN
2020-04-14 0:38 ` Marc MERLIN
2020-04-16 10:43 ` Anand Jain
2020-04-19 19:13 ` Marc MERLIN
2020-04-20 11:10 ` Anand Jain
2020-04-20 14:56 ` Marc MERLIN
2020-04-21 7:33 ` Anand Jain
2020-04-22 5:54 ` Marc MERLIN
2020-04-21 7:21 ` [PATCH] btrfs: boilerplate: devlist and fsinfo Anand Jain
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=20200326013007.GS15123@merlins.org \
--to=marc@merlins.org \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.com \
/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).