Re: Detecting new partitions fails after "btrfs device scan --forget"

[Jonas Zeiger <jonas.zeiger@talpidae.net>]

Seems like the following commit in 5.8.10 fixes the issue:

commit b730cc810f71f7b2126d390b63b981e744777c35
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Sep 8 16:15:06 2020 +0200

     block: restore a specific error code in bdev_del_partition

     [ Upstream commit 88ce2a530cc9865a894454b2e40eba5957a60e1a ]

     mdadm relies on the fact that deleting an invalid partition returns
     -ENXIO or -ENOTTY to detect if a block device is a partition or a
     whole device.

     Fixes: 08fc1ab6d748 ("block: fix locking in bdev_del_partition")
     Reported-by: kernel test robot <rong.a.chen@intel.com>
     Signed-off-by: Christoph Hellwig <hch@lst.de>
     Signed-off-by: Jens Axboe <axboe@kernel.dk>
     Signed-off-by: Sasha Levin <sashal@kernel.org>

On 2020-09-14 13:10, Jonas Zeiger wrote:
> Hi Anand,
> 
> Thank you for your assistance.
> 
> I enabled lock-stats in the kernel and stopped directly after
> initramfs boot from PXE:
> 
>  1. "partprobe" already fails even directly after boot, so my initial
> hunch that "btrfs device scan" is causing it is likely wrong.
> 
>  2. "lsof /dev/sdd" doesn't return anything and there is no mention of
> the device in "lsof" output.
> 
>  3. Nothing from disks is mounted, running only from tmpfs (unpacked
> from initramfs), almost no daemons (even killed smartd).
> 
>  4. "strace partprobe /dev/sdd" STDERR output is attached
> (strace-partprobe-dev-sdd.txt).
> 
>  5. I could not tell from "/proc/lock_stat" which lock could be
> responsible, if any, so I attached the file (lock_stat.txt).
> 
>  6. Partprobe's "ioctl(3, BLKPG, {op=BLKPG_DEL_PARTITION..." returns
> ENOMEM. Maybe I should mention that my kernel doesn't have swap
> (CONFIG_SWAP=n), but I guess ENOMEM means something different in this
> context. Also, why would it reliably work on 5.8.7.
> 
> I have set one host aside to help debug this issue as it prevents us
> from updating the kernel.
> 
> How can I help to further analyze this regression?
> 
> 
> On 2020-09-14 02:36, Anand Jain wrote:
>>> /dev/sda have been written, but we have been unable to inform the 
>>> kernel of the change, probably because it/they are in use.  As a 
>>> result, the old partition(s) will remain in use.  You should reboot 
>>> now before making further changes.
>>> 
>>> The partitions do not become visible so the deployment can't 
>>> continue.
>> 
>> The forget subcommand does not touch the mounted device, and it frees
>> only the unmounted or unopened btrfs devices from its kernel memory.
>> 
>> Now the error seems to be about the device being kept open. Can you
>> find out who did not close it?