From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB18EC433C1 for ; Tue, 30 Mar 2021 08:13:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8263A61983 for ; Tue, 30 Mar 2021 08:13:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231187AbhC3INA (ORCPT ); Tue, 30 Mar 2021 04:13:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231340AbhC3IMn (ORCPT ); Tue, 30 Mar 2021 04:12:43 -0400 Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF443C061762 for ; Tue, 30 Mar 2021 01:12:42 -0700 (PDT) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4F8hyK3pkkz1s0tN; Tue, 30 Mar 2021 10:12:41 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4F8hyK3RnSz1r1Mk; Tue, 30 Mar 2021 10:12:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id OQJTY4jcvuTW; Tue, 30 Mar 2021 10:12:40 +0200 (CEST) X-Auth-Info: Oh5lYsQS2QfE9UnE/VTYb5/nSTrsAprckz7CiU2KC3c= Received: from [10.88.0.186] (dslb-084-056-254-233.084.056.pools.vodafone-ip.de [84.56.254.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Tue, 30 Mar 2021 10:12:40 +0200 (CEST) Subject: Re: btrfs-send format that contains binary diffs To: Andrei Borzenkov , linux-btrfs@vger.kernel.org Cc: Henning Schild References: <5ba46b04-f3ba-03ef-6ad5-38fd44f8c67e@denx.de> <535709bb-0bde-6193-2cef-0c1d037ba211@gmail.com> <3cfc2421-4683-9439-1301-09d013a670ec@gmail.com> From: Claudius Heine Organization: Denx Software Engineering Message-ID: Date: Tue, 30 Mar 2021 10:12:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <3cfc2421-4683-9439-1301-09d013a670ec@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Hi Andrei, On 2021-03-30 07:38, Andrei Borzenkov wrote: > On 30.03.2021 08:33, Andrei Borzenkov wrote: >> On 29.03.2021 22:14, Claudius Heine wrote: >>> Hi Andrei, >>> >>> On 2021-03-29 18:30, Andrei Borzenkov wrote: >>>> On 29.03.2021 16:16, Claudius Heine wrote: >>>>> Hi, >>>>> >>>>> I am currently investigating the possibility to use `btrfs-stream` files >>>>> (generated by `btrfs send`) for deploying a image based update to >>>>> systems (probably embedded ones). >>>>> >>>>> One of the issues I encountered here is that btrfs-send does not use any >>>>> diff algorithm on files that have changed from one snapshot to the next. >>>>> >>>> >>>> btrfs send works on block level. It sends blocks that differ between two >>>> snapshots. >>> >>> Are you sure? >>> >> >> Yes. Ok, sorry for doubting you. My assumptions where wrong. >> >>> I did a test with a 32MiB random file. I created one snapshot, then >>> changed (not deleted or added) one byte in that file and then created a >>> snapshot again. `btrfs send` created a >32MiB `btrfs-stream` file. If it >>> would be only block based, then I would have expected that it would just >>> contain the changed block, not the whole file. And if I use a smaller >>> file on the same file system, then the `btrfs-stream` is smaller as well. >>> >>> I looked into those `btrfs-stream` files using [1] and also [2] as well >>> as the code. While I haven't understood everything there yet, it >>> currently looks to me like it is file based. >>> >> >> btrfs send is not pure block based image, because it would require two >> absolutely identical filesystems. It needs to replicate filesystem >> structure so it of course needs to know which files are created/deleted. >> But for each file it only sends changed parts since previous snapshot. >> This only works if both snapshots refer to the *same* file. >> > > Or more precisely - btrfs send knows which filesystem content was part > of previous snapshot and so is already present on destination and it > will not send this content again. It is actually more or less irrelevant > which files this content belongs to. I think I understood that now. > >> As was already mentioned, you need to understand how your files are >> changed. In particular, standard tools for software update do not >> rewrite files in place - they create new files with new content. From >> btrfs perspective they are completely different; two files with the same >> name in two snapshots do not share a single byte. When you compute delta >> between two snapshots you get instructions to delete old file and create >> new file with new content (that will be renamed to the same name as >> deleted old file). This also by necessity sends full new content. As you said, many standard tools create new files instead of updating files in place. But I guess a `dedupe` run before creating the snapshot could help here, right? If we have a root file system build process that always regenerates all files, and then copies those into a file system, then all files are 'different' from a btrfs perspective. >> So yes, btrfs replication is block based; similarity is determined by >> how much physical data is shared between two files. And you expect file >> based replication where file names determine whether files should be >> considered the same and changes are computed for two files with the same >> name. Right. Maybe we could use the file path just as a hint for an opportunity of saving resources by creating block based deltas. I guess I have to think about this some more. Thanks a lot! Claudius