Hello Theodore,
Is this case important enough to fix the code?
Thanks.
Best regards,
Artem Blagodarenko.
> On 19 Nov 2020, at 15:26, Lyashkov, Alexey <alexey.lyashkov@xxxxxxx> wrote:
>
> 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
>
