From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 156FC5A0276 for <passt-dev@passt.top>; Fri, 26 Apr 2024 04:01:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1714096870; bh=O3BtvCE+aOTW45wbtLKiYOqHSJUeeGVQ4GVAR9WMVbQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lifC4IWPEl1OapToynLVZzqxBg1fZm7EB1FF92Zeuqr2gkvybw0aIEnVt4NxbCLKk AlKGLoIJI9a4q2/gamHa/2WxDpSw0+qo4gy+6fDlSAydpkX4K1o4xoBXKSCJCFxB7X G075nAuc19IxkvMmvCTMHd8n9ke+El37xZfi+tjrkoXcND9m+scxGF1DiWN5RbY6xu isDrwDT7k2trLYTBgJJWFsn+xdJojSl5886Nr6SkRlYT4t8gS+63D+4cUrH9XAngWO hF+DLcSvhXlVVRHlffL7H5BDZESY5R+vrdMVyPQrNnTJpvQeRnu7Ya3lBNYRQc7SR5 qBib1EPY4SpEQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4VQbYL4zkVz4wyw; Fri, 26 Apr 2024 12:01:10 +1000 (AEST) Date: Fri, 26 Apr 2024 11:44:09 +1000 From: David Gibson <david@gibson.dropbear.id.au> To: Stefano Brivio <sbrivio@redhat.com> Subject: Re: [PATCH 2/4] Remove stale archivemount support Message-ID: <ZisG6T5Id4ngaPqJ@zatzit> References: <20240322022739.2746102-1-david@gibson.dropbear.id.au> <20240322022739.2746102-3-david@gibson.dropbear.id.au> <20240405200921.0a1f0318@elisabeth> <ZhC7YtfCeCAPSWEB@zatzit> <20240425064738.0368f902@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TfoFrcXEwL+v6P1i" Content-Disposition: inline In-Reply-To: <20240425064738.0368f902@elisabeth> Message-ID-Hash: AN6F4ZRUAPQBCMTG73WLBU3EB6VIKOPD X-Message-ID-Hash: AN6F4ZRUAPQBCMTG73WLBU3EB6VIKOPD X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: lvivier@redhat.com, passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt <passt-dev.passt.top> Archived-At: <https://archives.passt.top/passt-dev/ZisG6T5Id4ngaPqJ@zatzit/> Archived-At: <https://passt.top/hyperkitty/list/passt-dev@passt.top/message/AN6F4ZRUAPQBCMTG73WLBU3EB6VIKOPD/> List-Archive: <https://archives.passt.top/passt-dev/> List-Archive: <https://passt.top/hyperkitty/list/passt-dev@passt.top/> List-Help: <mailto:passt-dev-request@passt.top?subject=help> List-Owner: <mailto:passt-dev-owner@passt.top> List-Post: <mailto:passt-dev@passt.top> List-Subscribe: <mailto:passt-dev-join@passt.top> List-Unsubscribe: <mailto:passt-dev-leave@passt.top> --TfoFrcXEwL+v6P1i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2024 at 06:47:38AM +0200, Stefano Brivio wrote: > On Sat, 6 Apr 2024 14:02:58 +1100 > David Gibson <david@gibson.dropbear.id.au> wrote: >=20 > > On Fri, Apr 05, 2024 at 08:09:32PM +0200, Stefano Brivio wrote: > > > On Fri, 22 Mar 2024 13:27:37 +1100 > > > David Gibson <david@gibson.dropbear.id.au> wrote: > > > =20 > > > > mbuto has two ways of building the initramfs. One is the typical a= pproach > > > > of staging its contents in a temporary directory, then building the > > > > initramfs with cpio. The other is to create an empty initramfs, mo= unt > > > > it with archivemount, and copy things into the mounted archive. > > > >=20 > > > > However, the archivemount approach is broken. I'm not entirely sur= e why, > > > > but it appears not to properly unmount the archive and retrieve the= final. > > > > filled version. The upshot is that if archivemount is installed, t= hen > > > > mbuto generates an empty, gzip-compressed initramfs instead of what= ever it > > > > was supposed to. It looks like this has bitrotted from some earlier > > > > working version. > > > >=20 > > > > The archivemount approach is not necessary, and honestly a pretty s= trange > > > > and roundabout way of building the initramfs. Remove it. =20 > > >=20 > > > There were two reasons behind that: first off, I mistakenly assumed > > > that the kernel could see changes made to the initramfs after boot. = =20 > >=20 > > Yeah, that was never going to work. > >=20 > > > Second, it was actually convenient for developing this tool as I could > > > just make directories and copies in half-working images. I also had > > > half a mind about some usage with QEMU rebooting the guest, and the > > > initramfs would change across reboots without having to call mbuto > > > again, for bisections or suchlike. =20 > >=20 > > That's not really dependent on using archivemount in any case. If > > qemu re-reads the initrd on each boot, then you can still do this by > > rebuilding the image between boots (which is all that archivemount > > would do anyway). >=20 > That was exactly my point: with archivemount, the user doesn't have to > call mbuto again -- archivemount does it, implicitly. Not in a way that you can use safely. Archives are not a filesystem, let alone a filesystem designed for concurrent access from multiple parties. So, it's basically never going to be safe to read the archive independently while archivemount has it open for writing. If you're lucky, you might get what you want, but you could also get old contents because archivemount hasn't flushed out the changes yet (which is exactly what we saw). Or, worse, you could see a partly written archive, because you read when archivemount had started but not finished writing. Or, worse still, you could see inconsistent garbage, because you were reading partway through, then archivemount rewrote from the beginning. If you want this behaviour, you need something like virtio-fs or NFS. > > If qemu doesn't re-read it, then this won't work even if you are using > > archivemount. >=20 > It looks like QEMU doesn't do that, at least not on x86, so yes, this > part never worked anyway. >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --TfoFrcXEwL+v6P1i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmYrBugACgkQzQJF27ox 2GdZ0g//RAUOeITr1EDMugEezm/GQi1v7NWCKvaY4iiaKFAMa+tEXFZAM7vE4Gxi MN10JpE+lJfmgZuoSfd5tXAbrcCY5HZyXfweuCvy0Rph/vi28KBhBgNwA2j+AORv Tnu2oEg8rhkHKYVEfLyGcTUQ8R11/we4GmCrKIdIug5N0iWat3JuRXPIU/i9KEp6 jUmAsyKrYx8GfflZyATvu+u+cLItiki4FxffnDSzkkVKpZtwfOs9uZjQFEAXIEPh ug3dQZIXL8X1perUS1I8TCWvi9J6GjXu/kfiCVpzUrLVSmwC2cmjL9jij/T9RMWW oakXQRa9rKHEt0kkoLkROkVw+YOS1CAF8uMhMXYb5ZM/JIFQ8dO1DVdcvqU/UujJ JyVFVDXuVPq+tefCIBfMoXmMz9heIUb2HOuOSZiUhwiwALNcgE2uHRkfQ6U2Ujz6 Hs4+mX1deL6TnewqhD1uUqLqXNFhkxcx8Zc4YuNT591YY1vILCAuW+phSnlx+h9d j0DN9l12ageikF4/t1pVWeG2cs57iP0ijZ3k+E0KNUe4yqYy4+MQbs8O7VeFvYfs GDmF9huoVb0toinBgfDRaP9yb3TqO/GAoGUwb5CepK8uCkk4/xM3VAbB+aCrCCi3 cX/qmw0fxQ8XfcPSPWB16QlPNLi2xjtgzsPOjqk5TO9yoYlqZ+U= =f+JK -----END PGP SIGNATURE----- --TfoFrcXEwL+v6P1i--