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

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

[Anand Jain]

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.

Thanks, Anand

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

[Duncan]

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

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

[Austin S. Hemmelgarn]

On 2016-12-21 21:28, Anand Jain wrote:
>
> 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_ ?
While I didn't write the tool, I'm pretty certain that it was by design. 
  The primary use cases as I see them for compressing using defrag are:
1. Repacking files after mounting without compression (I do this myself 
whenever I have to boot into a different distro than what I already have 
on the system since I always use compress=none when mounting from 
recovery media).
2. Actually compressing files after marking them for compression.
3. Using multi-tier in-line compression (for example, 'live' data is LZO 
compressed, data which has sat idle for a while is ZLIB compressed).

>  The no-conflict fix will be to add another option to make
>  it persistent.
This ideally should be better documented (nothing says it will persist, 
but nothing I can find says it won't either), but I personally feel that 
defrag shouldn't be mucking about with file attributes beyond the stuff 
that's implicitly updated by shuffling extents around.