On 2021-06-05, Johannes Schauer Marin Rodrigues wrote:
> Quoting Vagrant Cascadian (2021-06-05 03:09:52)
>> When mmdebstrap produces a tarball directly, it sets different tarball
>> options:
>>
>> # tar2sqfs and genext2fs do not support extended attributes
>> if ($format eq "squashfs") {
>> warning("tar2sqfs does not support extended attributes"
>> . " from the 'system' namespace");
>> push @taropts, '--xattrs', '--xattrs-exclude=system.*';
>>
>> But if you're trying to generate a squashfs image with different default
>> compression (e.g. zstd), you have to pipe the mmdebstrap output to
>> tar2sqfs. But in this case, tar is not passed the above options, as it
>> is generating a tarball...
>
> yes. But you can filter the tarball and remove the system.* xattr later:
>
> mmdebstrap ... | mmtarfilter --pax-exclude=SCHILY.xattr.system.* | tar2sqfs
> ...
This might be worth mentioning in the mmdebstrap manpage! And updating
the mmtarfilter manpage with --pax-exclude too... :)
>> Maybe I'm missing something, but it would be very nice to be able to at least
>> append to options passed to tar2sqfs (presuming it doesn't error when passing
>> two different --compressor arguments), rather than having to extract them
>> from the manpage and/or code, especially given that the tar output changes
>> when you create a regular tarball vs. when mmdebstrap is aware that the
>> eventual destination is a squashfs...
>
> Is that such a common task? Are you running mmdebstrap manually and find
> yourself piping it to tar2sqfs by hand? Do you maybe suggest that the default
> options might need changing? I'm trying to understand your use-case here.
Well, *mostly* just to build zstd squashfs instead of xz (the
performance on various hardware I use is considerable better with zstd
defaults). Being able to set the compression type directly from
mmdebstrap would be nice!
I think I also needed to pipe to tar2sqfs manually in the past to
workaround bugs that I think have since been fixed (e.g. the
--xattrs-exclude patches).
The current default for tar2sqfs is xz, so passing --compressor xz is
redundant.
>> I'm also realizing that the squashfs call doesn't pass --num-jobs=0 to
>> tar2sqfs (similar to when creating a .tar.zst).
>
> Indeed that can be fixed.
Apparently, the default for tar2sqfs is number of cores:
--num-jobs, -j <count>
If libsquashfs was compiled with a thread pool based,
parallel data compressor, this option can be used to set
the number of compressor threads. If not set, the default
is the number of available CPU cores.
So I guess that's not needed at all.
live well,
vagrant
signature.asc
Description: PGP signature
