From: "Lyashkov, Alexey" <alexey.lyashkov@hpe.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>,
"Благодаренко Артём" <artem.blagodarenko@gmail.com>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"adilger.kernel@dilger.ca" <adilger.kernel@dilger.ca>,
Theodore Tso <tytso@google.com>
Subject: Re: [PATCH] libfs: Fix DIO mode aligment
Date: Thu, 19 Nov 2020 12:26:34 +0000 [thread overview]
Message-ID: <B8DE3834-1B3F-4E1E-B342-51E04E4FD278@hpe.com> (raw)
In-Reply-To: <20201117191918.GB529216@mit.edu>
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@mit.edu> 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
next prev parent reply other threads:[~2020-11-19 12:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 11:26 [PATCH] libfs: Fix DIO mode aligment Artem Blagodarenko
2020-11-17 15:30 ` Благодаренко Артём
2020-11-17 19:19 ` Theodore Y. Ts'o
2020-11-19 12:26 ` Lyashkov, Alexey [this message]
2020-12-08 8:33 ` Благодаренко Артём
2020-12-18 22:03 ` Andreas Dilger
2020-12-19 4:31 ` Lyashkov, Alexey
2021-02-26 23:17 ` Theodore Ts'o
2021-03-01 16:14 ` Благодаренко Артём
2021-03-01 17:42 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B8DE3834-1B3F-4E1E-B342-51E04E4FD278@hpe.com \
--to=alexey.lyashkov@hpe.com \
--cc=adilger.kernel@dilger.ca \
--cc=artem.blagodarenko@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).