Re: [PATCH 2/4] Remove stale archivemount support

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3394 bytes --]

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:
> 
> > 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:
> > >   
> > > > mbuto has two ways of building the initramfs.  One is the typical approach
> > > > of staging its contents in a temporary directory, then building the
> > > > initramfs with cpio.  The other is to create an empty initramfs, mount
> > > > it with archivemount, and copy things into the mounted archive.
> > > > 
> > > > However, the archivemount approach is broken.  I'm not entirely sure why,
> > > > but it appears not to properly unmount the archive and retrieve the final.
> > > > filled version.  The upshot is that if archivemount is installed, then
> > > > mbuto generates an empty, gzip-compressed initramfs instead of whatever it
> > > > was supposed to.  It looks like this has bitrotted from some earlier
> > > > working version.
> > > > 
> > > > The archivemount approach is not necessary, and honestly a pretty strange
> > > > and roundabout way of building the initramfs.  Remove it.  
> > > 
> > > There were two reasons behind that: first off, I mistakenly assumed
> > > that the kernel could see changes made to the initramfs after boot.  
> > 
> > Yeah, that was never going to work.
> > 
> > > 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.  
> > 
> > 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).
> 
> 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.
> 
> It looks like QEMU doesn't do that, at least not on x86, so yes, this
> part never worked anyway.
> 

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]