New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
udiskslinuxfilesystem: Make 'size' property retrieval on demand #949
Conversation
Filesystem size value retrieval is very expensive as it typically calls filesystem tools that read superblock -> doing some I/O. Other filesystem properties are typically retrieved from existing stateful sources, either udev or sysfs. This change overrides the gdbus-codegen-generated GDBusInterfaceSkeleton property retrieval and adds a custom hook that retrieves the filesystem size value when actually requested. One limitation of such approach is that the hook is called with the GDBusObjectManager lock held and thus it needs to be as minimal as possible and avoiding access to any GDBusObject.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
I think we have some more "expensive" properties in the encrypted interface, it might be worth changing these too. |
Hmm, there might be other candidates, might be interesting to revise all properties (except for modules perhaps) in all interfaces. However this is kind of experiment and a hack for the time being, let's see if this way proves itself over time with continuous testing. |
Filesystem size value retrieval is very expensive as it typically calls
filesystem tools that read superblock -> doing some I/O. Other
filesystem properties are typically retrieved from existing stateful
sources, either udev or sysfs.
This change overrides the gdbus-codegen-generated GDBusInterfaceSkeleton
property retrieval and adds a custom hook that retrieves the filesystem
size value when actually requested.
One limitation of such approach is that the hook is called with
the GDBusObjectManager lock held and thus the hook needs to be as minimal
as possible and needs to avoid any access to any GDBusObject.
TODO: handle ATA power management.
Fixes #946
Fixes #911
Fixes #871
Fixes #868