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

Add more advanced API #80

Open
Vaiz opened this issue Nov 2, 2024 · 3 comments
Open

Add more advanced API #80

Vaiz opened this issue Nov 2, 2024 · 3 comments

Comments

@Vaiz
Copy link

Vaiz commented Nov 2, 2024

First of all, thank you for maintaining this useful crate!

I would like to propose a few new additions to the API that I believe would benefit crate's users.

Return the operation used in reflink_or_copy

reflink_or_copy should return an enum indicating the operation performed:

enum OperationResult { Cloned, Copied }

This provides clearer feedback to the caller about the action taken. It can be useful for understanding the efficiency of cloning, space consumption, etc.

Add more functions:

  • fn is_reflink_supported(from: impl AsRef<Path>, to: impl AsRef<Path>) -> Result<SupportedStatus>
    enum SupportedStatus { Supported, NotSupported, Unknown }

This function would help to avoid unnecessary API calls if reflink is not supported, especially when copying large folders. It would also prevent unnecessary copying if cloning is expected to work. For example, blockcloning is not supported between different ReFS volumes, so it would be quite inefficient to use this function for copying a large directory.

  • fn reflink_block(file1: FileHandle, offset1: u64, size: u64, file2: FileHandle, offset2: u64) -> Result<()>

Adding block-level reflink capabilities allows for more granular and efficient data management. This can be particularly beneficial for applications that need to clone or deduplicate specific segments of large files.

@NobodyXu
Copy link
Member

NobodyXu commented Nov 2, 2024

Thanks!

I think OperationResult for reflink_or_copy is a very good idea.

For is_reflink_supported, I'd love to support it, but I'm not sure how to do it on Windows.
On Linux/Unix I know ioctl or procfs would probably provide some functionality.

For reflink_block, I think it's definitely possible on Windows, and likely possible on Linux with ioctl, but for MacOS/unix we might have to return io::ErrorKind::Unsupported

@Vaiz
Copy link
Author

Vaiz commented Nov 2, 2024

For is_reflink_supported, I'd love to support it, but I'm not sure how to do it on Windows.
On Linux/Unix I know ioctl or procfs would probably provide some functionality.

I can assist with Windows implementation. The key aspect here is to check if FILE_SUPPORTS_BLOCK_REFCOUNTING flag is set for a volume. This can be queried using GetVolumeInformationByHandle function or a similar API.

@NobodyXu
Copy link
Member

NobodyXu commented Nov 2, 2024

That'd be great!

I'm willing to do the review on any PR send in for this.

For the reflink_block, I think we can have best-effort implementation?
It can always return io::ErrorKind::Unsupported on platform that does not support it.

for is_reflink_supported, I think we should only return false if we are really sure this is not supported, I think false positive is worse than false negative here.

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

No branches or pull requests

2 participants