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.
--
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
