1

Background: I need to clone ext4 partitions from an eMMC using uboot (and if neccessary custom bare metal code). I copied the whole thing using mmc read and found that most of the partition is empty, but there are some blocks of data like inode tables spread across the partition. This would mean I need to copy the whole partition (which is too slow, I need to do this a lot) or identify what parts of the partition are relevant.

Most similar Q&A to this problem suggest to use dd creating a sparse image or piping to gzip, but I have no operating system running, so I need to understand the file system layout. Can I use those bitmap blocks to identify what is used and what is free? Documentation of ext4 seems to refer the linux kernel code as soon as it comes to details.

Preferably I'd do it with uboot code, but I could as well write some bare metal code I can execute from uboot.

One more border condition: The targets to where the partition gets clone are not empty, so if there are blocks of only zeros on the origin, which are required to be zero, I need to overwrite those blocks with zeros on the target.

Improve this question
3
  • Thinking sideways for a moment. Do you need to clone a partition when you run this code? Or could you (a) read the partition once and shrink the image by keeping only the non-zero blocks, (b) at deployment time unshrink the image by writing blocks to pre-specified locations on the disk? That would side-step the need to understand the on-disk filesystem format Commented Feb 6, 2018 at 7:57
  • Nearly. Except that the targets are not empty, so there could be blocks of only zeros on the origin which are relevant, so I need to overwrite the target block with zeros. Commented Feb 6, 2018 at 8:07
  • OK. It was just a thought. Commented Feb 6, 2018 at 9:05

2 Answers 2

Reset to default
0

If you can't mount the original filesystem in your environment, you could use debugfs to examine the filesystem layout, and copy the files to your target. With a bit of work you could script debugfs to list, traverse, copy the original filesystem into a temporary location, then use mke2fs -d to write it to the new filesystem, or just copy it to the target location directly.

If you are willing to write your own code, you can use libext2fs to open the filesystem, read the directory tree, and recursively copy it to the target filesystem (which could also be opened using libext2fs). This would be much easier than writing any of your own code to handle the on-disk ext4 format.

If the barrier to accessing the eMMC device as a block device in your environment (sorry, I don't know anything about that, just the ext4 side) then you could write a custom IO driver for libext2fs (like lib/ext2fs/unix_io.c or .../nt_io.c) that can read/write eMMC devices directly, then use debugfs+scripts or a custom libext2fs copy tool.

Improve this answer
0

Use e2image -ar to copy the relevant parts of the filesystem. It understands the filesystem and copies all needed metadata, and data blocks used by files, while skipping unused space.

Improve this answer

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.