3

I've got an Ubuntu 20 virtual machine running in qemu that uses a qcow2 disk file with another qcow2 disk file as backing store. The VM was built from a recent Canonical-distributed cloud image with cloud-init.

As soon as I start it up, its disk file starts getting bigger and bigger at a rate of about a gigabyte every five minutes.

It's an ext4 file system and no swap is configured. The thin provisioned disk image is configured for 1 TB, with only 4.2 GB actually in use; the disk image itself is 4.4 GB. All the virtual machine is doing is booting and starting its GUI.

"iotop" shows "ext4lazyinit" running, so I think it's initializing inode tables.

When I shut it down and check its disk image with debugfs's "dump_unused", it shows all kinds of random data in its unused disk blocks.

What I don't understand is why it's doing this if the disk is zero'ed, and why it writes all this random clutter.

Are empty inode tables all zero on ext4? Does it perhaps write a small portion of a disk block as an inode table, then the rest of the disk block is filled with junk instead of being all zeros? Any way to get it to write zeros instead of garbage?

Improve this question
1
  • I waited until ext4lazyinit finished, and the disk file had ballooned to 28 GB. Then I shut down the VM, zerofree'd the disk image, rebased it and copied to it a new file that's only 4.5 GB (102 MB bigger than the original). Sure seems like an awfully convoluted procedure. Commented Apr 24, 2022 at 2:19

1 Answer 1

Reset to default
3

This is the ext4 lazy_itable_init thread that is zeroing out the inode tables after mount, instead of doing it as part of mke2fs. In e2fsprogs commit v1.46.4-25-gbd2e72c5c552 a patch was landed (mke2fs: Add extended option for prezeroed storage devices) to add the -E assume_storage_prezeroed option so that you can tell it that the device is already zeroed and not to do an explicit overwrite the inode table blocks. That should avoid increasing the size of the disk image, and also avoid extraneous disk IO at initial mount time.

While it appears that this commit would be in the 1.46.5 release, it looks like it is only on the master branch and will likely only be packaged in a 1.47-based release unless you build e2fsprogs from source (either the master branch, or cherry-pick this patch to maint).

Improve this answer
6
  • Sounds great! Any idea how to set that option on a cloud image where the filesystem has already been created and is only being extended, probably during cloud-init? If not, I'll try to dope it out myself.. Commented Apr 24, 2022 at 13:10
  • Looks like Ubuntu 20 is running an earlier version of e2fsprogs, 1.45.5 Commented Apr 24, 2022 at 14:44
  • It's not in Ubuntu 22 either, which is running 1.46.5. According to this, that patchset was left out by mistake. Commented Apr 24, 2022 at 19:03
  • To clarify - it was left out of e2fsprogs-1.46.5, not left out of Ubuntu 22 Commented Apr 24, 2022 at 19:14
  • It doesn't look like there's any way to disable this feature once it's been enabled, so it continues to be a problem for cloud images that come pre-built from a vendor (like Ubuntu and Canonical). Commented Apr 25, 2022 at 17:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.