There is a problem with btrfs partition unmount

[HeroesLoveToRoujiamo]

The U disk is formatted into multiple btrfs file system partitions. When the U disk is directly pulled out, only one btrfs file system partition can be unmounted.

The reason for this problem is:
When the U disk is pulled out, udisks_state_check_mounted_fs_entry() will unmount the first btrfs partition first. Then mounts_changed_event() is triggered. Causes the udisks_state_check_mounted_fs_entry function to be called and UDisksMountMonitor *monitor to be updated. The remaining btrfs partitions will enter the udisks_mount_monitor_parse_mountinfo() function when unmounted, namely:

if (major == 0)
        {
……

              if (stat (mount_source, &statbuf) != 0)
                {
                  udisks_warning ("Error statting %s: %m", mount_source);
                  continue;
                }

              if (!S_ISBLK (statbuf.st_mode))
                {
                  udisks_warning ("%s is not a block device", mount_source);
                  continue;
                }

              dev = statbuf.st_rdev;
            }

Since the U disk has been pulled out, "stat (mount_source, &statbuf)" cannot obtain the device file information, so an exception occurs.

[tbzatek]

There are many issues currently when it comes to multidisk btrfs volumes. There are some related changes in #838 but that work isn't finished at the moment.

[HeroesLoveToRoujiamo]

The #838 project should take a bit more time to complete, until then, the #976 code commit can be considered in order for btrfs to be uninstalled properly, provided of course that it does not introduce other problems. In particular, the benefits of introducing this solution in the current maintenance release should be even greater.Thanks！

[tbzatek]

Hmm, looking at your pull request #976 and reading the story here, I don't think that introducing a big UDisksMountMonitor lock is the correct way forward. By nature the UDisksState thread is set to operate in a raceful environment and should deal with missing information on its own. There's too many accesses to UDisksMountMonitor from different places and this would introduce a risk of a circular deadlock.

The UDisksMountMonitor parser looks correct - if the a mounted filesystem entry points to an invalid block device that couldn't be stat()-ed, such record should be deemed invalid (not taking UUID-based filesystems in account at the moment).

If I understand your issue properly, you're facing exactly what #838 is supposed to solve. The udisks_state_check_mounted_fs_entry() will currenly fail to match the other devices due to a different block device numbers.

[HeroesLoveToRoujiamo]

I modified the code of #976:
udisks_state_check_mounted_fs() obtains the mounts information of the monitor in advance and passes it to the udisks_state_check_mounted_fs_entry() function, so that the uninstallation process will not be affected by the monitor update.

Thanks！