Hi, > I don't know whether this demand, which specified some subvolumes > or directories to be compressed, conflict with the design of > btrfs's compression feature, may be they want to do this thing > well, and everyone will enable the compression feature, rather > than throw the decision to user to determine which should > compress.
You can't tell whether you can compress data well until you've already spent CPU compressing it, though. Right now we have a useful metric of "if parts of the file fail to compress, bail out on compressing the rest of the file, both now and in the future"; but it's only a metric. There are cases this fails on, such as a tar archive that starts out with JPEGs and continues with large (compressible) text files. I think the argument that we don't need to offer user control because we can just do a good job all the time only works if it's actually true that we can do a good job all the time, and I don't think that's true here. So, I still support user control of the per-inode flag. (I agree about the subvol flags; I think being able to set quotas and compression per-subvol is on the roadmap and just not done yet.) -- Chris Ball <c...@laptop.org> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
