Re: [bug or by design ?] btrfs defrag compression does not persist

[Duncan <1i5t5.duncan@cox.net>]

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