Skip to content
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

Merged
merged 3 commits into from Jan 17, 2022

Conversation

tbzatek
Copy link
Member

@tbzatek tbzatek commented Jan 2, 2022

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

@tbzatek tbzatek marked this pull request as ready for review January 5, 2022 19:25
@tbzatek tbzatek changed the title WIP: udiskslinuxfilesystem: Make 'size' property retrieval on demand udiskslinuxfilesystem: Make 'size' property retrieval on demand Jan 5, 2022
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.
Copy link
Member

@vojtechtrefny vojtechtrefny left a 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.

@vojtechtrefny
Copy link
Member

I think we have some more "expensive" properties in the encrypted interface, it might be worth changing these too.

@tbzatek
Copy link
Member Author

tbzatek commented Jan 17, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants