On 06/15/2010 02:43 PM, Jim Meyering wrote: > I think that copying physical holes via FIEMAP should be the default, when > possible. One problem is that the current code on the fiemap-copy branch > does not honor --sparse=WHEN when in fiemap-copying mode. The solution > would seem to be to change the regular-file-copying loop in the fiemap_copy > function to use the same hole-preserving code that is used in copy_reg.
I assume that the solution would be used only with cp --sparse=always? (Otherwise, it would amount to copying logical holes by default.) If so, under this proposal, --sparse=always would copy logical holes, --sparse=never would never copy holes, and --sparse=auto (the default) would copy physical holes if supported, else it would copy logical holes if the file seems to have enough physical holes, and otherwise it would copy no holes. (Whew!) But this raises another issue. Under this proposal, the default behavior copies physical _holes_, but it doesn't copy physical _extents_. For example, suppose the input file has a single 128 MiB extent. The proposal could create an output file with two 64-MiB extents that are logically contiguous. This is because the code does not advise the output file about the extents that the input file had, and the operating system might assign a smaller output extent at first, discovering only too late that more space was needed. If the intent is to copy the physical extents, then the proposed code needs to be fixed so that it uses fallocate() to attempt to create the same extents in the destination that existed in the source. Obviously this could fail for any number of reasons, for example, the destination file system might be different from the source; but the goal would be to preserve extents if the underlying OS is "nice" about implementing fallocate(). Which raises another question: should cp attempt to create _better_ extents in the destination than in the source? For example, if the source contains two logically-adjacent 64-MiB extents, should the destination contain just one 128-MiB extent? I can see where that might be worthwile. This all is getting a bit complicated, I'm afraid. Perhaps it'd be better to try this stuff out with a new option, "cp --sparse=extents" say, and keep the default as-is for a while?
