On 9/4/17, 11:03 AM, "linux-btrfs-owner@xxxxxxxxxxxxxxx on behalf of David Sterba" <linux-btrfs-owner@xxxxxxxxxxxxxxx on behalf of dsterba@xxxxxxx> wrote:
> On Wed, Aug 30, 2017 at 02:53:22PM -0700, Nick Terrell wrote:
> > Adds zstd support to the btrfs program, and a dependency on libzstd >=
> > 1.0.0.
>
> I'm afraid we'll have to make the build optional for now, as the distros
> may not provide it and I'd like to give at least some heads-up first. My
> idea is:
>
> - check if zstd library is found, use it
> - otherwise warn that's it's going to be on by default in near future
I can see a few options, what do you want to see?
1. Require zstd for building `btrfs' but statically link it so users don't
need to have zstd installed, unless they install from source.
2. Require zstd to build `btrfs', but dynamically link and use `dlopen' and
`dlsym' to access the decompression function (and check the library
version).
3. Make zstd optional in the build process, and completely disable it if
unavailable. Otherwise dynamically link and do the same as (2).
4. Same as (3) but statically link if it is available.
I'm thinking that (3) is the best option for consistency with the other
libraries, at the expense of making the user install zstd if they want to
use it. We can put a nice warning message in `btrfs restore' that says you
need to install zstd.
> 'btrfs restore' would need to be enhanced to dump what's built in (in a
> similar way convert now prints the supported filesystem), and possibly
> warn that there are data compressed by zstd but there's no
> decrompression support.
Sounds good.
> > The patch is also available in my fork of btrfs-progs [1], which passes
> > Travis-CI. I tested each command that is effected in my test script [2].
>
> The test requires zstd kernel support, which may be not available for
> some time in the testing environments. But as restore is userspace-only,
> we can create and use various images with zstd compressed data.
I'll modify my tests and add them to the test suite.
> > I haven't updated Android.mk since I have no way to test it, and am not
> > certain if it is used.
>
> The anodroid build verification will work eventually through travis and
> I'm aware it could be out of sync, you don't need to care about that
> right now.
��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
