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

Try using fs_at #174

Open
sourcefrog opened this issue Aug 5, 2022 · 3 comments
Open

Try using fs_at #174

sourcefrog opened this issue Aug 5, 2022 · 3 comments

Comments

@sourcefrog
Copy link
Owner

sourcefrog commented Aug 5, 2022

Context: #172 (comment)

Using fs_at would potentially reduce time spent both constructing paths, and inside the kernel on parsing and traversing paths.

This probably needs to be threaded through the Transport layer, as not all transports will support the same concept.

This could be implemented independently on both source/restore trees, and archives.

I don't think this is a dominant performance driver at the moment but it might be interesting.

To do this usefully I think we'd need ReadDir equivalent (rbtcollins/fs_at#11).

cc @rbtcollins fyi

@sourcefrog
Copy link
Owner Author

To use fs_at, it would have to also support stating files and reading links, which it currently does not, but which could be possible with readlinkat and fstatat.

@rbtcollins
Copy link

fstat : https://doc.rust-lang.org/std/fs/struct.File.html#method.metadata [if you want to minimise calls, open() + fstat is cheaper than fstatat () + open() + fstat() to check it is still what you expected.]

readlinkat is probably needed, haven't gotten that far yet :P .

@sourcefrog
Copy link
Owner Author

https://github.com/sourcefrog/cp_r/compare/fs_at?expand=1 is an experiment towards using fs_at in a similar but smaller crate.

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

No branches or pull requests

2 participants