On 2019/1/4 上午11:43, Chris Murphy wrote:
> On Thu, Jan 3, 2019 at 6:32 PM Qu Wenruo <[email protected]> wrote:
>>
>>
>>
>> On 2019/1/4 上午9:15, Chris Murphy wrote:
>>> If you use btrfs-image -ss option, there won't be any sensitive
>>> information included. Files are hashed. Some short name files or dirs
>>> can't be hashed (you'll see a warning) and those are replaced with
>>> random garbage instead. There is only metadata with the image, no user
>>> data.
>>
>> Please don't advice -ss for btrfs-image. It's super slow and will easily
>> cause tons of noise when running btrfs check on it.
> 
> I thought in recent btrfs-progs that -ss was quite a bit faster. The
> last time I used it I don't think it was much slower than -s. Anyway I
> don't have a preference between hash or garbage, but I don't think
> it's realistic for users to give out filenames in images. So is -s OK?

For -s/-ss the problem is, btrfs check will report tons of hash
mismatch, and recent kernel will even refuse to mount due to enhanced
dir item hash check.

The extra problem of -ss is, it can't ensure all filenames to have a
conflict hash, so it's not that much different from -s.


For User don't want to give any filenames, then don't give any files names.
We could find a way to get needed info just using btrfs ins dump-tree,
especially for this case where only one error is reported.

Thanks,
Qu

> 
> 
> 

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to