On Wed, Jun 28, 2023 at 05:31:37PM +0200, Christoph Hellwig wrote: > Currently the logic whether to compress or not in compress_file_range is > a bit convoluted because it tries to share code for creating inline > extents for the compressible [1] path and the bail to uncompressed path. > > But the latter isn't needed at all, because cow_file_range as called by > submit_uncompressed_range will already create inline extents as needed, > so there is no need to have special handling for it if we can live with > the fact that it will be called a bit later in the ->ordered_func of the > workqueue instead of right now. > > [1] there is undocumented logic that creates an uncompressed inline > extent outside of the shall not compress logic if total_in is too small. > This logic isn't explained in comments or any commit log I could find, > so I've preserved it. Documentation explaining it would be appreciated > if anyone understands this code. > Looks like it's just a optimization, no reason to allocate a whole async extent if we can just inline a page and be done. It's not necessarily required, but could use a comment. Thanks, Josef