Tso,
This situation hit with modern hdd with 4k block size and e2image changed to use DIRECT IO instead of buffered.
e2fsprogs tries to read a super lock on offset 1k and it caused to set FS block size to 1k and second block reading.
(many other places exist, but it simplest).
>>
if (superblock) {
if (!block_size) {
retval = EXT2_ET_INVALID_ARGUMENT;
goto cleanup;
}
io_channel_set_blksize(fs->io, block_size);
group_block = superblock;
fs->orig_super = 0;
} else {
io_channel_set_blksize(fs->io, SUPERBLOCK_OFFSET); <<<<< this is problem
superblock = 1;
group_block = 0;
retval = ext2fs_get_mem(SUPERBLOCK_SIZE, &fs->orig_super);
if (retval)
goto cleanup;
}
retval = io_channel_read_blk(fs->io, superblock, -SUPERBLOCK_SIZE,
fs->super);
>>
It caused errors like
# e2image -Q /dev/md65 /tmp/node05_image_out
e2image 1.45.6.cr1 (14-Aug-2020)
e2image: Attempt to read block from filesystem resulted in short read while trying to open /dev/md65
Couldn’t find valid filesystem superblock.
It looks like I don't first person to found a bug, as someone was add
Alex
On 17/11/2020, 22:19, "Theodore Y. Ts'o" <tytso@xxxxxxx> wrote:
On Tue, Nov 17, 2020 at 06:30:11PM +0300, Благодаренко Артём wrote:
> Hello,
>
> Any thoughts about this change? Thanks.
I'm trying to think of situations where this could actually trigger in
real life. The only one I can think of is if a file system with a 1k
block file system is located on an an Advanced FormatDrive with a 4k
sector size.
What was the use case where this was actually an issue?
- Ted
