3

Filesystems like ext4 are block-aligned, meaning files are aligned to blocks of a predefined size, typically 4 KB in the case of ext4. If an .img file is created from such a filesystem, can I assume that the individual files are 4k aligned in the created .img file, just like they are in the real filesystem?

In other words, say we have two 1 KB files called foo and bar, which appear on the physical drive as below, with each [] representing 1 KB.

[foo][][][][bar][][][]

In this case, foo and bar are 4k aligned. Now, if we create an .img file for this filesystem, are the contents of foo and bar still 4k aligned from the start bit of the img file?

New contributor
Dennis is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

1 Answer 1

10

Define "an img file". If you mean a simple copy (e.g. from cp /dev/sdx1 file.img, dd if=/dev/sdx1 of=file.img, cat /dev/dsx1 > file.img, pv …, …) then you don't have to think about "an img file created from the filesystem". It's a copy of the filesystem, so a filesystem as well.

The only difference is the original filesystem exists (usually) on a block device, while the copy exists as a regular file you call "an img file". But it's the same sequence of bytes (until one of the filesystems is mounted and thus altered). You can mount the copy and use it.

So yes, every structure or alignment from the original (with respect to the beginning of the original block device) also exists in the copy (this time with respect to the beginning of the regular file).

4
  • In my case, I created an ext4 filesystem using mke2fs, then add files to it using e2fsdroid. Then I ended up with an img file that can be mounted.
    – Dennis
    2 days ago
  • @Dennis: Right, so it's an image created the same way as if done on a block device. This answer still applies. The fact that it can be mounted tells you that the data layout within the file is valid for the filesystem, and ext2/3/4 filesystems align their stuff in blocks. (It doesn't just choose to do that based on detecting the logical sector size of the device it's creating on; I assume it stores "pointers" (e.g. from inode to actual data extents) on disk in a format that assumes the low N bits are zero, not actually storing those low bits to save space / make larger FSes possible) yesterday
  • @Dennis So the fragment "if an .img file is created from such a filesystem" does not really describe your case. Your mke2fs had to assume some block size anyway. If it was on a block device, the tool would check the physical sector size and adjust its default values if needed (see man 8 mke2fs, -b option). In a regular file there is no such thing as sectors, still some block size had to be used and it's probably some sane value. I'm not sure if the tool checks the block size of the filesystem holding the file. Anyway, internally in the filesystem blocks of some size are used for sure. yesterday
  • But would the byte boundaries in the file align with the byte boundaries on the disk? That's what I took the OP as asking.
    – trlkly
    yesterday

Your Answer

Dennis is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.