On 8/8/26 10:37 AM, Matthew Sakai wrote: > Thank you for your patience. This took me longer to get to than I had hoped. No worries! > If you have data handy from these experiments, it would be interesting to see > it. This is the sort of information that would go well in a cover letter > explaining what you want to do, and why. At any rate, if you have cases that > seem to benefit from this, we can certainly revisit whether this is worth > adding. > Another thing to consider is that we originally chose the LZ4 algorithm > because it is fairly cheap to compute. If you can, it's worth trying to > quantify what the extra computational load does to vdo throughput, especially > with fast storage. The throughput for a vdo volume will often lag the raw > storage speed significantly (due to the deduplication machinery) and it's > worth knowing if changing the algorithm will make that worse.
Yes, I'll make sure to include more details in the future. > I appreciate that you're attempting to minimize disruption. I admit that it > is simpler, in terms of pure implementation, to make this a format-time > choice. However, imagine what happen next: Long-time vdo users will inquire > whether they can use this new feature, and we will have to tell them no. For > new users, I think they may not know all the data they will store on a volume > up front, but they will be locked into their first choice. Given the > case-by-case variability of the tradeoff, I expect users will appreciate > being able to change this setting to fit their current needs. > In short, doing this as a format-only option looks like implementing half a > feature to me, and I think we would be better off starting with full > flexibility. Also remember that every version of this feature that we expose > to users is a feature we will have to maintain for the lifetime of the dm-vdo > driver, and I would rather not have to support both versions. > (I believe the difference in complexity is also not that large, but that's a > bit more subjective. Setting the algorithm as a run-time option means > extending the compressed block format, but adding a format-time option > involves more work updating the user space tools, including the formatter. > Both options also require updating the table line and the super block format, > so there's also considerable overlap.) Personally, the superblock modifications felt quite concerning at first glance, but that seems less like a huge issue, if it is justified. > So anyway. If you can show there is utility in doing this, we can look at > adding it. I will probably want to do it by building on what we did last > year, though. You can look at what I've already done on the branch > feature/allow-compression-configuration in the vdo-devel project. I haven't > rebased the branch in a while, but you can get an idea of how I was planning > the table line and super block changes, at least. Thank you June
