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

Please support in-place writing of nested images #285

Open
helmutg opened this issue Mar 23, 2025 · 6 comments
Open

Please support in-place writing of nested images #285

helmutg opened this issue Mar 23, 2025 · 6 comments

Comments

@helmutg
Copy link

helmutg commented Mar 23, 2025

When writing an ext4 or vfat image to a partition, the filesystem image is first created and then copied. Given larger images (e.g. including Gnome), this poses a non-trivial slowdown (especially when the /tmp location is not yet tmpfs). Many of the filesystem management utils now support offesets and sizes and therefore support in-place creation in a larger image in principle.

For instance mkfs.ext4 has -E offset=.... For mtools, the offset can be added to an image filename after @@.

@jluebbe
Copy link
Member

jluebbe commented Mar 24, 2025

Alternatively, using FICLONERANGE when supported would give faster "copies" almost everywhere in genimage. I'd expect that we have the necessary alignment (4kiB, I think) in almost every case.

@michaelolbrich
Copy link
Member

Or copy_file_range(). But I don't think either is supported by ext4, so while it would be a nice fallback, we should still implement writing in place.

@jluebbe
Copy link
Member

jluebbe commented Mar 24, 2025

Or copy_file_range(). But I don't think either is supported by ext4, so while it would be a nice fallback, we should still implement writing in place.

As far as I can see, the flag to enable reflink/clone was never implemented for copy_file_range(), so FICLONERANGE is the better choice here.

Writing in place would target the first disk image using that filesystem? And copy to others from there? It seems that would be complex to implement.

@michaelolbrich
Copy link
Member

I would implement in place only if the fs image is used exactly once.

@michaelolbrich
Copy link
Member

That's the common use-case and I think it makes sense to optimize that

@helmutg
Copy link
Author

helmutg commented Mar 24, 2025

The downside of using copy_file_range and such is that intermediate images tend to be stored in /tmp which tends to be tmpfs these days and the target image tends to be stored elsewhere, so you're crossing a filesystem boundary here and as a result those nice kernel features may not apply.

I concur with optimizing the common case (image being used exactly once). What is requested here is an optimization and not expected to pose a semantic difference.

I recommend labeling the issue wishlist in any case.

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

3 participants