Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: [PATCH] libfs: Fix DIO mode aligment
From:   =?utf-8?B?0JHQu9Cw0LPQvtC00LDRgNC10L3QutC+INCQ0YDRgtGR0Lw=?= 
        <artem.blagodarenko@gmail.com>
In-Reply-To: <B8DE3834-1B3F-4E1E-B342-51E04E4FD278@hpe.com>
Date:   Tue, 8 Dec 2020 11:33:27 +0300
Cc:     "Theodore Y. Ts'o" <tytso@mit.edu>,
        "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
        "adilger.kernel@dilger.ca" <adilger.kernel@dilger.ca>,
        Theodore Tso <tytso@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1485E4F8-618E-408C-B390-E4B093EC89EF@gmail.com>
References: <20201023112659.1559-1-artem.blagodarenko@gmail.com>
 <19A3D721-93C0-42F3-ACBA-DE15B4685F9F@gmail.com>
 <20201117191918.GB529216@mit.edu>
 <B8DE3834-1B3F-4E1E-B342-51E04E4FD278@hpe.com>
To:     "Lyashkov, Alexey" <alexey.lyashkov@hpe.com>
Precedence: bulk

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@hpe.com> =
wrote:
>=20
> Tso,
>=20
> 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).
>>>=20
>        if (superblock) {
>                if (!block_size) {
>                        retval =3D EXT2_ET_INVALID_ARGUMENT;
>                        goto cleanup;
>                }
>                io_channel_set_blksize(fs->io, block_size);
>                group_block =3D superblock;
>                fs->orig_super =3D 0;
>        } else {
>                io_channel_set_blksize(fs->io, SUPERBLOCK_OFFSET); =
<<<<< this is problem
>                superblock =3D 1;
>                group_block =3D 0;
>                retval =3D ext2fs_get_mem(SUPERBLOCK_SIZE, =
&fs->orig_super);
>                if (retval)
>                        goto cleanup;
>        }
>        retval =3D io_channel_read_blk(fs->io, superblock, =
-SUPERBLOCK_SIZE,
>                                     fs->super);
>>>=20
> 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=E2=80=99t find valid filesystem superblock.
>=20
> It looks like I don't first person to found a bug, as someone was add=20=

>=20
> Alex
>=20
> =EF=BB=BFOn 17/11/2020, 22:19, "Theodore Y. Ts'o" <tytso@mit.edu> =
wrote:
>=20
>    On Tue, Nov 17, 2020 at 06:30:11PM +0300, =D0=91=D0=BB=D0=B0=D0=B3=D0=
=BE=D0=B4=D0=B0=D1=80=D0=B5=D0=BD=D0=BA=D0=BE =D0=90=D1=80=D1=82=D1=91=D0=BC=
 wrote:
>> Hello,
>>=20
>> Any thoughts about this change? Thanks.
>=20
>    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.
>=20
>    What was the use case where this was actually an issue?
>=20
>         	     	      	    	     - Ted
>=20