On Sun, Nov 01, 2015 at 08:41:05AM +0100, Celelibi wrote:
>
> When the file system size is not given, mke2fs determine the appropriate
> size by using the size of the support device. However, when the extended
> option "offset" is given, it doesn't seem to reduce the fs size to take
> the offset into account.
>
> An actual case of this bug can be when the support "device" is a regular
> file and the size of the file system is not given because it's the last
> partition in the virtual disk.
So this is tricky. I will grant that if this is a physical disk, and
you specify an offset, and mke2fs tries to figure out the size of the
physical disk, it shouldn't make a file system which won't work ---
and we know the physical device is 10M, and you have specified an
offset of 4M, then the file system length should be 6M or the
resulting file system will have some real problems.
There are two problems with just always reducing the fs size to take
the offset into account. First of all, if the user explicitly
requests the creation of a file system of a specific size, reducing it
just because an offset was specified doesn't make sense. For example:
mke2fs -E offset=8M /tmp/foo.img 2M
If the user asked for a 2M file system, she should get a 2M file
system. Certainly creating a file system of size -6M doesn't make any
sense!
The second problem is that users who try ro rely on this are very
likely to get them selves in trouble. For example, what if the user
had done this instead:
1) Create a virtual disk
qemu-img create -f raw testing.img 20M
2) Create several partitions
parted -s testing.img mklabel gpt
parted -s -a none testing.img mkpart ESP fat32 0 4M
parted -s -a none testing.img mkpart linux ext4 4M 10M
parted -s -a none testing.img mkpart linux ext4 10M 20M
And now the user does this:
mke2fs -E 4000256 testing.img
No mattter what, it's going to do the wrong thing, because it can't
really "automatically figure out the file system size". (For one
thing, mke2fs has no idea whether you are using GPT, or the FAT
partition table, or LVM for that matter.)
So in general, the only reliably consistent thing the user can do is
to always specify the file system size when the specifying the offset
--- and not trying to do something crazy like subtracting the offset
from the file system size.
> Proposed solution:
> 1) Take the offset into account when computing the optimal file system
> size.
Only if the file system size is not specified.
> 2) Emit a warning when the offset option is given without a file system
> size and the support file is a regular file instead of a block device as
> it may overwrite subsequent partitions if it's not the last one.
Sure, although I think I'll do it *all* the time. If you are using
the offset, you're doing something weird, even if you are using a block device.
- Ted
