udiskslinuxfilesystem: Update udisks_linux_filesystem_update() call

[HeroesLoveToRoujiamo]

When the udisks_linux_filesystem_update() function calls the
udisks_linux_filesystem_update() function, it adopts a
multi-threaded method. Prevent the main process from
freezing when a certain device resource is occupied.
#871

Signed-off-by: changlianzhi changlianzhi@uniontech.com

[StorageGhoul]

Can one of the admins verify this patch?

[HeroesLoveToRoujiamo]

Since org.freedesktop.UDisks2.Filesystem.Size is necessary at all times, then we use multi-threading to solve this problem, what do you think?@tbzatek

[tbzatek]

I appreciate your effort, unfortunately uevent processing chain needs to be done entirely in the main thread. This is the fundamental requisite which other objects depend on, i.e. having the org.freedesktop.UDisks2.Filesystem interface completely updated as a result of a uevent being processed so that methods waiting in other threads can continue their work. Complex storage layers like LVM2 also require up-to-date information on related block objects that provide necessary information to build a layered object on.

We've spent considerable amount of time to ensure predictability of the UDisks API for scripting purposes where serialization is a key and async approach is a big problem.

Believe me, we've been dealing with this exact problem in the past yet there's no suitable solution without breaking the ABI or API. A solution might be to rewrite bd_fs_ext3_get_info() and others to avoid spawning an external command and rather parse the data from kernel or a runtime state somewhere with minimal I/O.

[HeroesLoveToRoujiamo]

Thank you very much. It seems that my understanding of udisks2 is far from enough and I haven't considered these issues. Let me try it hard!