Re: race condition mounting multi-device iscsi volume, not resolved in newer kernels

[Eric Levy <contact@ericlevy.name>]

On Sat, Jul 22 2023 at 07:50:38 PM +0800, Anand Jain 
<anand.jain@oracle.com> wrote

>>  Hm. Do you mean the filesystem is in an inconsistent state after
>  the manual successful manual mount? Do you have any error/warn logs?
>  What tells you that the filesysem is inconsistent?

The state inconsistency refers to the mount session not to the file 
system. The file system is completely healthy, having been cleanly 
unmounted during the previous shutdown sequence, and no mount operation 
having been completed during the current boot session.

However, within the running session, the system reports the file system 
being already mounted, when mounting is attempted, even though the 
mount point is empty and the mount operation had produced failure 
messages.

> Devid 8! How many devices do we have to this fsid?
> As before do you have the dump-super?
> 
> Do you have -o degraded in the mount option?
> 
> Before (what ever is) calling the mount has it run
>  btrfs device scan  ?

The system has eight devices. The first two are system devices, the 
remaining ones comprise the spanned volume.

I have not attempted mounting in degraded mode, nor would I do so, 
since the file system itself is healthy, and I wish to keep it as such. 
All of the failures have been failures to mount due to some devices 
being unattached. As long as the system is not mounting cleanly, then 
not mounting remains preferred, to maintain its health.

> So what is the time diff between above two messages?
> Already mounted => might be due to a race condition?

I could check the timestamps, but the differences I am certain are less 
than one second. The messages are printed sequentially, and operations 
are clearly not in the preferred order. Mounting should not be 
attempted until all devices are attached.

> Scanned messages appearing after the an attempt to mount so for sure 
> mount shall fail.

Right.