Anand Jain posted on Thu, 22 Dec 2016 10:28:28 +0800 as excerpted: > A quick design specific question. > > The following command converts file-data-extents to the specified > encoder (lzo). > > $ btrfs filesystem defrag -v -r -f -clzo dir/ > > However the lzo property does not persist through the file modify. > As the above operation does not update the btrfs.compression property. > > Question: > I wonder if this should be a bug or if its by design ? What could be > the main use case to _associate compression at the time of defrag_ ? > The no-conflict fix will be to add another option to make it > persistent. I'd say it's a feature (whether deliberately designed that way or not). Presumably, if you want real-time compression, you're using the appropriate mount option or already setting the property on the file(s) in question. Which leaves defrag-with-compression runs for one-time compression of cold data that's unlikely to change further, or for periodic compression runs during slow periods or the like, when you know it's not going to be an issue, even if it would be an issue if done in real-time production, thus the reason you're not running with the option already. A practical example would be someone using the compress=lzo mount option for real-time work, then using defrag-and-compress to compress to zlib level either during slow periods, or when files have been rotated out of active use and are no longer being actively rewritten/appended. They don't /want/ further modifications compressed to the same level in real- time. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
