Austin S. Hemmelgarn posted on Wed, 15 Nov 2017 07:57:06 -0500 as excerpted:
> The 'compress' and 'compress-force' mount options only impact newly > written data. The compression used is stored with the metadata for the > extents themselves, so any existing data on the volume will be read just > fine with whatever compression method it was written with, while new > data will be written with the specified compression method. > > If you want to convert existing files, you can use the '-c' option to > the defrag command to do so. ... Being aware of course that using defrag to recompress files like that will break 100% of the existing reflinks, effectively (near) doubling data usage if the files are snapshotted, since the snapshot will now share 0% of its extents with the newly compressed files. (The actual effect shouldn't be quite that bad, as some files are likely to be uncompressed due to not compressing well, and I'm not sure if defrag -c rewrites them or not. Further, if there's multiple snapshots data usage should only double with respect to the latest one, the data delta between it and previous snapshots won't be doubled as well.) While this makes sense if you think about it, it may not occur to some people until they've actually tried it, and see their data usage go way up instead of going down as they intuitively expected. There have been posts to the list... Of course if the data isn't snapshotted this doesn't apply and defrag -c to zstd should be fine. =:^) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
