2016-05-01 5:50 UTC+02:00, Theodore Ts'o <ty...@mit.edu>: > 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.
Well, this is not what I suggested. I suggested that the automatic determination of the filesystem size (when it's not explicit) should subtract the offset from the size of the device or file. 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 >
